Sistema Web Control-Desbloqueado

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y

NATURALES CARRERA DE INFORMATICA
PROYECTO DE GRADO
“SISTEMA WEB PARA EL CONTROL Y SEGUIMIENTO DE
AFILIADOS A LOS ENTES GESTORES
CASO: INSTITUTO NACIONAL DE SEGUROS DE SALUD INASES”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMATICA
MENCION: INGENIERIA DE SISTEMAS INFORMATICOS
POSTULANTE: JOSE MANUEL LOZA TROCHE

TUTOR METODOLÓGICO: M. Sc. ALDO RAMIRO VALDEZ ALVARADO
ASESORA: Lic. BRIGIDA ALEXANDRA CARVAJAL BLANCO
LA PAZ – BOLIVIA
2015
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN
ANDRÉS AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
DEDICATORIA
A mi mAdre AlEJANDRA Troche, por DARme lA VidA, por quererme
mucho, por creer en mí, por ApoYARme, esTAndo siempre dispuesTA sin
espERAr NADA A CAmbio, todo esto te lo debo A ti. GRACIAs MAMÁ.
A mi pAdre JUAn CArlos LoZA, por ensEÑARMe el vAlor de LA
persevERANCIA, por ensEÑARMe A ser fuerte Ante los problemAs, y por
hAberme DADO UNA EDUCACIón excelente. GRACIAs PApÁ.
A mi ABUELA Mercedes SullCAtA (Q.E.P.D.) y mi tÍA RAquelin Troche
(Q.E.P.D.), porque en vIDA me motivAron A perseguir mis sueños y
porque me desmostRAron su cAriño. MuchAs gRACIAs.
A mis hERMAnos EFRAÍN LoZA y DAniel LoZA, por hAberme ApoYADO en
sITUACIones difíciles, y por DARme motivos pARA sAlir AdelAnte juntos.
GRACIAs.
AGRADECIMIENTOS
Agradecer primeramente al Ing. Julio Prieto Peñaranda y al Lic. Roger Navia
Gutiérrez, por apoyarme constantemente en la elaboración de este proyecto y
más que todo por su amistad.
Agradecer a mi tutor M.Sc. Aldo Ramiro Valdez Alvarado quien me ha
orientado en todo momento en la realización de este proyecto.
Agradecer a mi asesora Lic. Brigida Alexandra Carvajal Blanco, por su
dedicación de tiempo, por sus correcciones y aportes que fueron importantes
para la finalización de este trabajo.
Agradecer a las personas que me apoyaron, me motivaron, y me contribuyeron
en la finalización de este proyecto.
Y finalmente agradezco a los juegos Warcraft y Starcraft por haberme
inspirado y motivado a estudiar la carrera de informática.
…. Muchas gracias!
RESUMEN
Los entes gestores de Bolivia, son instituciones que conforman el sistema se seguros de
salud a corto plazo, estos tienen la obligación dar atención médica a trabajadores y sus
familias. Actualmente realizan sus actividades de forma descentralizada y trabajan de
manera independiente en el manejo de su información de sus afiliados. Es por ello que una
persona para poder recabar información sobre su estado de afiliación en los distintos entes
gestores debe apersonarse a los entes gestores y conseguir certificación de cada uno de
ellos, este proceso dura 1 día o más dependiendo del esfuerzo de la persona.
El presente proyecto de grado tiene como propósito desarrollar un sistema web para el
control y seguimiento del estado de afiliación de las personas en los entes gestores para el
Instituto Nacional de Seguros de Salud (INASES).
El sistema web fue desarrollado bajo la metodología de desarrollo ágil de software

SCRUM, cuyo objetivo primordial es elevar al máximo la productividad de un equipo y la
metodología de modelado web UWE, que proporciona herramientas para la ingeniería de
aplicaciones Web.
Con el sistema web se pueden registrar afiliados a una única base de datos, de esta manera
se obtendrá la información integra de la población asegurada. También controla que una
persona no se pueda registrar más de una vez y protegerá la información con seguridad
lógica.
Además el sistema beneficiara a las personas ya que contara con la información actualizada
del estado de afiliación de toda la población asegurada, por ello se podrá proporcionar
certificados de no afiliación de manera rápida y eficiente. Por otro lado también se
beneficiara a las empresas que podrán generar planillas, para que puedan realizar trámites
con los entes gestores.
ÍNDICE
CAPITULO I........................................................................................................................................1
MARCO REFERENCIAL...................................................................................................................1
1.1 INTRODUCCIÓN................................................................................................................1
1.2 ANTECEDENTES...............................................................................................................2
1.2.1 ANTECEDENTES INSTITUCIONALES.......................................................................2
1.2.2 PROYECTOS SIMILARES.............................................................................................4
1.3 PLANTEAMIENTO DEL PROBLEMA.............................................................................6
1.3.1 PROBLEMA CENTRAL.................................................................................................6
1.3.2 PROBLEMAS SECUNDARIOS.....................................................................................7
1.4 DEFINICIÓN DE OBJETIVOS..........................................................................................7
1.4.1 OBJETIVO GENERAL...................................................................................................7
1.4.2 OBJETIVOS ESPECÍFICOS...........................................................................................7
1.5 JUSTIFICACIÓN.................................................................................................................8
1.5.1 ECONÓMICA..................................................................................................................8
1.5.2 SOCIAL............................................................................................................................8
1.5.3 TÉCNICA.........................................................................................................................8
1.6 ALCANCES Y LÍMITES....................................................................................................9
1.6.1 ALCANCES.....................................................................................................................9
1.6.2 LÍMITES..........................................................................................................................9
1.7 APORTES..........................................................................................................................10
1.7.1 TEÓRICO.......................................................................................................................10
1.7.2 PRÁCTICO....................................................................................................................10
CAPITULO II.....................................................................................................................................11
MARCO TEÓRICO...........................................................................................................................11
2.1 INGENIERIA DE SOFTWARE........................................................................................11
2.1.1 METODOLOGIAS DE DESARROLLO.......................................................................11
2.1.1.1 METODOLOGIAS DE DESARROLLO AGILES...............................................12
2.2 METODOLOGÍA DE DESARROLLO ÁGIL SCRUM...................................................16
2.2.1 ¿QUÉ ES SCRUM?........................................................................................................16
2.2.2 ROLES...........................................................................................................................17
2.2.3 HERRAMIENTAS Y PRÁCTICAS..............................................................................17
2.2.4 FASES DEL SCRUM....................................................................................................19
i
2.2.4.1 PRE JUEGO (PRE GAME)...................................................................................20
2.2.4.2 JUEGO (GAME)....................................................................................................21
2.2.4.3 POST JUEGO (POST GAME)..............................................................................23
2.3 ARQUITECTURA DE SOFTWARE................................................................................23
2.3.1 ARQUITECTURA 3 CAPAS........................................................................................23
2.3.2 BALANCEO DE CARGA EN LOS SERVIDORES....................................................25
2.3.3 BASE DE DATOS ESPEJO..........................................................................................25
2.4 INGENIERÍA WEB...........................................................................................................25
2.4.1 APLICACIÓN WEB......................................................................................................26
2.4.2 SEGURIDAD INFORMATICA....................................................................................27
2.4.2.1 SEGURIDAD LOGICA.........................................................................................27
2.5 UWE...................................................................................................................................30
2.5.1 ¿QUÉ ES UWE?............................................................................................................30
2.5.2 MODELOS.....................................................................................................................30
2.5.2.1 MODELO DE REQUISITOS................................................................................30
2.5.2.2 MODELO DE CONTENIDO................................................................................32
2.5.2.3 MODELO DE NAVEGACIÓN.............................................................................32
2.5.2.4 MODELO DE PRESENTACIÓN..........................................................................34
2.6 BASES DE DATOS...........................................................................................................35
2.6.1 DESNORMALIZACIÓN...............................................................................................36
2.7 TECNOLOGIAS WEB......................................................................................................36
2.7.1 PHP.................................................................................................................................37
2.7.2 FRAMEWORK YII2.....................................................................................................37
2.7.3 BOOTSTRAP.................................................................................................................38
2.7.4 APACHE........................................................................................................................39
2.7.5 MARIADB.....................................................................................................................40
CAPITULO III...................................................................................................................................42
MARCO APLICATIVO....................................................................................................................42
3.1 INTRODUCCIÓN..............................................................................................................42
3.2 PRE JUEGO.......................................................................................................................43
3.2.1 DESCRIPCION DE USUARIOS..................................................................................43
3.2.2 PRODUCT BACKLOG.................................................................................................43
3.2.3 REQUERIMIENTOS DE HARDWARE Y SOFTWARE............................................46
3.3 JUEGO...............................................................................................................................46
ii
3.3.1 SPRINT 1.......................................................................................................................47
3.3.1.1 PLANIFICACIÓN.................................................................................................47
3.3.1.2 DESARROLLO......................................................................................................47
3.3.1.3 PRUEBAS..............................................................................................................55
3.3.2 SPRINT 2.......................................................................................................................56
3.3.2.1 PLANIFICACIÓN.................................................................................................56
3.3.2.2 DESARROLLO......................................................................................................56
3.3.2.3 PRUEBAS..............................................................................................................60
3.3.3 SPRINT 3.......................................................................................................................60
3.3.3.1 PLANIFICACIÓN.................................................................................................60
3.3.3.2 DESARROLLO......................................................................................................60
3.3.3.3 PRUEBAS..............................................................................................................65
3.3.4 SPRINT 4.......................................................................................................................65
3.3.4.1 PLANIFICACIÓN.................................................................................................65
3.3.4.2 DESARROLLO......................................................................................................66
3.3.4.3 PRUEBAS..............................................................................................................71
3.3.5 SPRINT 5.......................................................................................................................71
3.3.5.1 PLANIFICACIÓN.................................................................................................71
3.3.5.2 DESARROLLO......................................................................................................72
3.3.5.3 PRUEBAS..............................................................................................................78
3.3.6 SPRINT 6.......................................................................................................................79
3.3.6.1 PLANIFICACIÓN.................................................................................................79
3.3.6.2 DESARROLLO......................................................................................................79
3.3.6.3 PRUEBAS..............................................................................................................82
3.4 POST JUEGO.....................................................................................................................82
3.4.1 PRUEBAS DE INTEGRACIÓN...................................................................................83
3.4.2 PRUEBAS DE SISTEMA..............................................................................................83
CAPITULO IV...................................................................................................................................96
CALIDAD Y SEGURDAD DEL SOFTWARE................................................................................96
4.1 NORMA ISO 9126.............................................................................................................96
4.1.1 FUNCIONALIDAD.......................................................................................................97
4.1.2 CONFIABILIDAD.......................................................................................................101
4.1.3 USABILIDAD..............................................................................................................102
4.1.4 MANTENIBILIDAD...................................................................................................103
iii
4.1.5 PORTABILIDAD........................................................................................................104
4.1.6 CALIDAD GLOBAL...................................................................................................105
4.2 SEGURIDAD...................................................................................................................105
4.2.1 AUTENTIFICACIÓN..................................................................................................106
4.2.2 SEGUIMIENTO A LAS ACCIONES DE LOS USUARIOS.....................................106
4.2.3 ENCRIPTACIÓN.........................................................................................................107
4.2.4 SEGURIDAD EN LA BASE DE DATOS..................................................................107
CAPITULO V..................................................................................................................................108
ANÁLISIS DE COSTOS.................................................................................................................108
5.1 MODELO COCOMO II...................................................................................................108
5.2 CALCULO DE COSTOS................................................................................................109
5.3 BENEFICIO.....................................................................................................................111
5.3.1 VALOR ACTUAL NETO (VAN)...............................................................................111
5.3.2 TASA INTERNA DE RETORNO (TIR).....................................................................112
5.4 COSTO BENEFICIO.......................................................................................................113
CAPITULO VI.................................................................................................................................114
CONCLUSIONES Y RECOMENDACIONES...............................................................................114
6.1 CONCLUSIONES............................................................................................................114
6.2 RECOMENDACIONES..................................................................................................115
BIBLIOGRAFÍA..............................................................................................................................116
ANEXOS..........................................................................................................................................120
iv
ÍNDICE DE FIGURAS
Figura 2.1: Fases del SCRUM............................................................................................................19
Figura 2.2: Arquitectura 3 capas........................................................................................................24
Figura 2.3: Esquema básico de una aplicación web...........................................................................26
Figura 2.4: Iconos de los estereotipos para el diagrama de casos de uso...........................................31
Figura 2.5: Ejemplo de diagrama de casos de uso.............................................................................31
Figura 2.6: Ejemplo de diagrama de contenido..................................................................................32
Figura 2.7: Iconos de los estereotipos para el diagrama de navegación.............................................32
Figura 2.8: Ejemplo de diagrama de navegación...............................................................................33
Figura 2.8: Iconos de los estereotipos para el diagrama de presentación...........................................34
Figura 2.9: Ejemplo de diagrama de presentación.............................................................................35
Figura 3.1: Modelo del proceso de desarrollo del proyecto...............................................................42
Figura 3.2: Modelo Relacional de la Base de Datos..........................................................................48
Figura 3.3: Diseño de la arquitectura de software..............................................................................55
Figura 3.4: Diagrama de Casos de Uso de los requisitos Autentificación de Usuarios y Mostrar
acciones de usuarios...........................................................................................................................57
Figura 3.5: Diagrama de Contenido de los requisitos Autentificación de Usuarios y Mostrar
Figura 3.6: Diagrama de Navegación de los requisitos Autentificación de Usuarios y Mostrar
Figura 3.7: Modelo de Presentación de la autentificación de Usuarios.............................................58
Figura 3.8: Diagrama de Presentación del Sistema Web...................................................................59
Figura 3.9: Modelo de Presentación de Mostrar acciones de usuarios..............................................59
Figura 3.10: Diagrama de Casos de Uso de los requisitos Crear/Actualizar Empleador y
Crear/Actualizar Beneficiarios...........................................................................................................61
Figura 3.11: Diagrama de Contenidos de los requisitos Crear/Actualizar Empleador y
Crear/Actualizar Beneficiarios...........................................................................................................61
Figura 3.12: Diagrama de Navegación del requisito Crear/Actualizar Empleadores........................62
Figura 3.13: Diagrama de Navegación del requisito Crear/Actualizar Beneficiarios........................62
Figura 3.14: Diagrama de Presentación del requisito Crear/Actualizar Empleadores.......................63
Figura 3.15: Modelo de Presentación de Crear/Actualiza Beneficiarios...........................................64
Figura 3.16: Modelo de Presentación de Listar Beneficiarios...........................................................64
v
Figura 3.17: Diagrama de Casos de Uso de los requisitos Generar/Actualizar Planillas y Generar
Reportes de las planillas.....................................................................................................................66
Figura 3.18: Diagrama de Contenidos de los requisitos Generar/Actualizar Planillas y Generar
Reportes de las planillas.....................................................................................................................67
Figura 3.19: Modelo de Navegación de Crear/Actualizar Planillas...................................................67
Figura 3.20: Diagrama de Presentación de Generar Planilla..............................................................68
Figura 3.21: Diagrama de Presentación de Lista de Planillas............................................................69
Figura 3.22: Diagrama de Presentación de Crear/Añade Beneficiarios.............................................69
Figura 3.23: Diagrama de Presentación de Listar Beneficiarios........................................................70
Figura 3.24: Diagrama de Presentación de reporte planilla PDF.......................................................70
Figura 3.25: Diagrama de Casos de Uso de los requisitos Administrar Privilegios de Usuarios y
Administrar solicitudes de cambio de datos de beneficiarios............................................................72
Figura 3.26: Diagrama de Contenidos de los requisitos Administrar Privilegios de Usuarios y
Administrar solicitudes de cambio de datos de beneficiarios............................................................73
Figura 3.27: Diagrama de Navegación de administrar grupos...........................................................74
Figura 3.28: Diagrama de Navegación de Asignar Grupos................................................................74
Figura 3.29: Diagrama de Navegación de Administrar solicitudes de cambio de datos de
beneficiarios.......................................................................................................................................75
Figura 3.30: Diagrama de Presentación de la Administración de Usuarios.......................................76
Figura 3.31: Diagrama de Presentación del Formulario App.............................................................76
Figura 3.32: Diagrama de Presentación del Formulario Grupo.........................................................76
Figura 3.33: Diagrama de Presentación del Formulario Acceso........................................................77
Figura 3.34: Diagrama de Presentación de la Lista de Usuarios que es parte de Asignar Grupos.. . .77
Figura 3.35: Diagrama de Presentación de los Datos y Grupos de un Usuario que es parte de
Asignar Grupos...................................................................................................................................78
Figura 3.36: Diagrama de Casos de Uso de los requisitos Generar Certificado de no afiliación a los
entes gestores y Generar Certificado de afiliación a un ente gestor..................................................80
Figura 3.37: Diagrama de Contenidos de los requisitos Generar Certificado de no afiliación a los
Figura 3.38: Diagrama de Navegación de los requisitos Generar Certificado de no afiliación a los
Figura 3.39: Diagrama de Presentación de Formulario Certificado...................................................81
Figura 3.40: Diagrama de Presentación de Certificado Único de Afiliación.....................................82
Figura 3.41: Pantalla principal del sistema SisAf..............................................................................84
vi
Figura 3.42: Pantalla de autentificación.............................................................................................85
Figura 3.43: Pantalla de la Lista de Log.............................................................................................85
Figura 3.44: Pantalla del Formulario de Usuario...............................................................................86
Figura 3.45: Pantalla del Formulario de Beneficiario........................................................................87
Figura 3.46: Pantalla del Formulario de Beneficiario........................................................................87
Figura 3.47: Pantalla de Generar una nueva Planilla.........................................................................88
Figura 3.48: Pantalla la Lista de Planillas.........................................................................................88
Figura 3.49: Pantalla del Formulario de Beneficiario en Planillas....................................................89
Figura 3.50: Pantalla la Lista de Beneficiarios en Planillas..............................................................89
Figura 3.51: Pantalla del Reporte PDF de Planillas.........................................................................90
Figura 3.52: Pantalla de Administrar Menús.....................................................................................91
Figura 3.53: Pantalla de Formulario de Acceso................................................................................91
Figura 3.54: Pantalla de Formulario de Acceso................................................................................91
Figura 3.55: Pantalla de Formulario de App.....................................................................................92
Figura 3.56: Pantalla de la Lista de Usuarios....................................................................................92
Figura 3.57: Pantalla de la Lista de Usuarios....................................................................................93
Figura 3.58: Pantalla del formulario de Certificado...........................................................................94
Figura 3.59: Pantalla del Certificado Único de Afiliación.................................................................95
Figura 4.1: Fragmento de código de validación JavaScript.............................................................106
Figura 4.2: Seguimiento a las acciones de usuarios por el sistema..................................................106
Figura 4.3: Encriptación AES en PHP.............................................................................................107
Figura 5.1: Inserción de datos para COCOMO II............................................................................109
Figura 5.2: Resultado de la estimación de costos.............................................................................110
vii
ÍNDICE DE TABLAS
Tabla 2.1: Metodología Ágil vs. Metodología Tradicional................................................................16
Tabla 2.2: Tareas de la fase Pre-juego...............................................................................................21
Tabla 2.3: Actividades de SCRUM....................................................................................................23
Tabla 2.4: Estereotipos para el diagrama de casos de uso..................................................................31
Tabla 2.5: Estereotipos para el diagrama de navegación...................................................................33
Tabla 2.5: Estereotipos para el diagrama de presentación.................................................................34
Tabla 3.1: Descripción de Usuarios...................................................................................................43
Tabla 3.2: Product Backlog................................................................................................................46
Tabla 3.3: Requerimientos de Hardware y Software el desarrollo del proyecto................................46
Tabla 3.4: Sprint Backlog 1................................................................................................................47
Tabla 3.5: Diccionario de datos de la base de datos del sistema web................................................54
Tabla 3.6: Pruebas unitarias del sprint 1............................................................................................55
Tabla 3.8: Pruebas unitarias del sprint 2............................................................................................60
Tabla 3.10: Pruebas unitarias del sprint 3..........................................................................................65
Tabla 3.11: Sprint Backlog 4..............................................................................................................66
Tabla 3.12: Pruebas unitarias del sprint 4.........................................................................................71
Tabla 3.17: Pruebas de integración del sistema web..........................................................................83
Tabla 4.1: Parámetros de medida y su cantidad.................................................................................98
Tabla 4.2: Cálculo de la cuenta total..................................................................................................98
Tabla 4.3: Valores de ajuste de complejidad....................................................................................100
Tabla 4.4: valores de confiabilidad de cada modulo........................................................................101
Tabla 4.5: Encuesta sobre la usabilidad del sistema........................................................................103
Tabla 4.6: Información requerida por el IMS...................................................................................103
Tabla 4.7: Calidad Global del Sistema Web....................................................................................105
Tabla 4.8: Funciones de Seguridad en Yii2.....................................................................................107
Tabla 5.1: Flujo de caja por años.....................................................................................................112
viii
CAPITULO I
MARCO REFERENCIAL
1.1 INTRODUCCIÓN
Las nuevas tecnologías tienen una gran influencia en la velocidad de trabajar en una
empresa, instituto, entidad, etc. Es por eso que un sistema de información puede ayudar al
rápido manejo de la información de una entidad, para mejorar la calidad de servicios que
estas ofrecen. El internet hoy en día se ha transformado en una herramienta indispensable
para cualquier tipo de empresa y entidades públicas como privadas. El que una empresa o
entidad tenga su sistema de información web le trae beneficios a la misma, entre los
beneficios más destacados se encontrarían el brindar información detallada de servicios de
forma rápida a los usuarios, que la información que se brinda esté disponible para todo el
mundo, y automatizar algunas operaciones. Es por eso que es imprescindible que una
empresa o entidad cuente con su sistema, porque si sucediese lo contrario esta se
encontraría en desventaja frente a otras que cuenten con su sistema.
El Seguro de Salud nace en Bolivia en 1956 con la creación de la Caja Nacional de Salud,
la cual brinda un seguro a los trabajadores que tienen relación obrero-patronal. Este sistema
ha hecho que la población trabajadora está protegida y cuente con una amplia gama de
atención médica. Después de la Caja, el Estado creó el Seguro Básico de Salud para la
atención de mujeres y niños en los hospitales públicos de manera gratuita. Ese Seguro fue
reforzado, posteriormente, con el Seguro Universal Materno-Infantil SUMI, el mismo que
actualmente sigue vigente y beneficia a los niños de cero a cinco años, y a las mujeres
embarazadas hasta los seis meses después del parto. Asimismo, se incorporó el Seguro de
Vejez, hoy, llamado Seguro del Adulto Mayor que tiene como beneficiarios a las personas
de 60 años para adelante. Y así con el tiempo se fueron creando más seguros de salud para
los bolivianos.
Los entes gestores (seguros de salud) de Bolivia, son instituciones que conforman el
sistema se seguros de salud a corto plazo, estos tienen la obligación dar atención médica a
trabajadores y sus familias de manera oportuna, eficiente, económica y con calidad.
Actualmente los entes gestores realizan sus actividades de forma descentralizada, estos
trabajan de manera independiente en el manejo de su información como también en el uso
de sus herramientas.
El presente proyecto es acerca del proceso que las personas siguen para obtener un
certificado de no afiliación a distintos entes gestores (seguros de salud). En este sentido el
Instituto Nacional de Seguros de Salud, con la realización de un sistema web pretende
recolectar la información sobre los afiliados a los distintos entes gestores, así tener
información integra y con ello beneficiar a las personas que necesitan obtener su certificado
de no afiliación de distintos entes gestores.
El proyecto será desarrollado bajo la metodología de desarrollo ágil SCRUM y UWE para
el modelado del sistema. El sistema web funcionara en 4 servidores inicialmente y los
cuales también servirán para el almacenamiento de la información que los empleadores
proporcionaran al sistema; de esta manera la información de los afiliados se centralizara en
una base de datos. El sistema tendrá seguridad lógica en varios niveles para proteger el
sistema web y la base de datos.
1.2 ANTECEDENTES
1.2.1 ANTECEDENTES INSTITUCIONALES

El Instituto Nacional de Seguros de Salud (INASES) es una entidad desconcentrada del
Ministerio de Salud y Deportes, tiene su sede principal en la ciudad de La Paz y unidades
operativas desconcentradas en los departamentos y regiones. El INASES tiene la
competencia de fiscalizar el Sistema Nacional de Seguros de Salud, con la atribución
general de la evaluación y supervisión sobre los Entes Gestores y Seguros Delegados en el
marco de la normativa vigente; para que se otorguen prestaciones de salud en los regímenes
de
2
enfermedad, maternidad y riesgos profesionales a corto plazo de manera oportuna, eficiente
y económica. [D.S. No 25798]
Según el [D.S. No 25798], el INASES fiscaliza a los siguientes Entes Gestores del Sistema
de Seguros de Salud:
 Caja Nacional de Salud.

 Caja Petrolera de Salud.
 Caja Bancaria Estatal de Salud.
 Caja de Salud de la Banca Privada.
 Caja de Salud de Caminos.
 Seguros Sociales Universitarios.
 Caja de Salud CORDES.
 Seguros Delegados.
Algunos conceptos importantes que se dan a continuación se manejan con frecuencia:
 AFILIACIÓN.- Registro de empresas, instituciones e inscripción del trabajador,

esposa, concubina, esposo, padres e hijos y personas sin relación de dependencia al
Seguro Social de Corto Plazo.
 DESAFILIACIÓN.- Proceso que deben seguir las empresas e instituciones a

solicitar el cambio de su actual ente gestor por razones fundamentadas, justificadas
y verificadas por el Instituto Nacional de Seguros de Salud (INASES).
 REAFILIACIÓN.- Proceso determinado mediante Resolución Administrativa

emitida por el INASES por el cual las empresas, instituciones, trabajadores y
beneficiarios deben registrarse en el mismo Ente Gestor.
 ENTE GESTOR DE SALUD.- Persona Jurídica de derecho público

descentralizado, con autonomía de gestión, administrativa, financiera, legal y
técnica, con patrimonio propio, responsable de la gestión, aplicación y ejecución
delos seguros de
3
enfermedad, maternidad y riesgos profesionales de Corto Plazo establecidos en el
Código de Seguridad Social y disposiciones legales conexas.
 TRABAJADOR ASEGURADO.- Es aquella persona, sea obrero, empleado o

directivo sujeto al campo de aplicación del Seguro Social de Corto plazo.
 BENEFICIARIOS.- Los miembros de la familia del asegurado protegidos por las

disposiciones del Código de Seguridad Social y disposiciones legales conexas.
 PRESTACIONES.- Beneficios otorgados en especie y/o en dinero por el Seguro

Social de Corto Plazo, para la protección del trabajador y su familia.
El INASES en su calidad de entidad fiscalizadora a los entes gestores (seguros de salud a

corto plazo) está desarrollando e implementando un sistema web para integrar la
información de los afiliados a los entes gestores con el fin consolidar la población protegida
y poder brindar el estado de afiliación de una persona en los entes gestores.
1.2.2 PROYECTOS SIMILARES

En la carrera de informática de la Universidad Mayor de San Andrés, se encuentran varios
proyectos realizados relacionados con sistemas de afiliación, a continuación se mencionan
algunos ordenados cronológicamente para ver que herramientas y metodologías se usaron
en los años de su realización:
 “SISTEMA DE AFILIACION Y SERVICIOS MEDICOS PARA UNA CAJA DE

SALUD”.- Sistema que registra nuevos afiliados, proporciona información
actualizada (historial clínico y estadísticas), y procesa ordenes médicas
(ambulatoria, exámenes, recetas y bajas médicas). Se desarrolló en plataforma
UNIX, con el lenguaje Progress y RDBMS (Relational database management
system) para la base de datos. [ALANDIA, 1997]
 “SISTEMA DE REGISTRO Y CONTROL DE AFILIACION – SEGURO
SOCIAL UNIVERSITARIO”.- Sistema que facilita el flujo de información
involucrada, en el registro y control de afiliados del seguro social universitario de
la paz SSU-LP. El
4
sistema puede registrar nuevos afiliados, proporcionar información actualizada, y
generar reportes estadísticos. Desarrollado con la metodología de ingeniería de
software Metrica Version 3. [VILA, 2004]
 “SISTEMA DE AFILIACION Y CONTROL DE AFILIACION – CAJA
PETROLERA DE SALUD”.- En este proyecto se desarrolló e implemento un
Sistema de información que automatiza el proceso de afiliación y reportes de los
afiliados de la caja petrolera de salud. Dicho sistema puede registrar nuevos
afiliados, obtener reportes y generar listados. Desarrollado con la Metodología
Estructurado Modern y con herramientas PHP y MySQL. [COPA, 2004]
 “SISTEMA DE INFORMACION Y AFILIACION VIA WEB DEL SEGURO DE
SALUD PARA EL ADULTO MAYOR- DIRECCION DE ASLUD GOBIERNO
MUNICIPAL DE EL ALTO”.- En este proyecto se desarrolló un Sistema de
Información vía web que cumple con políticas de seguridad y da niveles de acceso a
los usuarios. Con el sistema se puede registrar nuevos afiliados, realizar consultas y
búsquedas acerca de los afiliados como también obtener reportes. Este proyecto se
desarrolló con las metodologías UML (Unified Modeling Languaje) y OOHDM
(Object Oriented Hypermedia Design Method). [LUJAN, 2008]
En el internet podemos encontrar varios servicios web de otros países, los cuales cumplen
un objetivo similar al que el presente proyecto pretende llegar:
 “SERVICIO SUPER EN LINEA” .- Servicio del sistema web de la

superintendencia de salud de Chile , que proporciona un Documento que acredita la
afiliación de una persona a una Institución de Salud Previsional (ISAPRE) y la
calidad de beneficiario (cotizante o carga) que posee en un determinado contrato de
salud. [SUPERSALUD, 2015]
 “CONSULTA DE AFILIADOS”.- Un servicio web del sistema de la
superintendencia de Banca, Seguros y AFP de Perú, en el cual un usuario puede
averiguar si está afiliado al Sistema Privado de Pensiones (SPP). [SBS, 2015]
5
1.3 PLANTEAMIENTO DEL PROBLEMA
1.3.1 PROBLEMA CENTRAL

La información sobre los afiliados a los distintos entes gestores es descentralizada porque
los entes gestores manejan su información de manera independiente. Es por eso que una
persona para recolectar la información de su estado de afiliación que tiene en los distintos
entes gestores, debe apersonarse personalmente a los entes gestores para llenar un
formulario con sellos o adquirir certificados que los entes gestores proveen, un ejemplo se
puede ver en el ANEXO D, este proceso puede tardar 1 día o más días dependiendo del
tiempo que la persona disponga para poder apersonarse a todos los entes gestores, ya que
estos tienen diferentes direcciones y se encuentran cercanas o alejadas unas de otras.
La información que obtiene la persona demuestra que dicha persona no se encuentra

afiliada a los entes gestores o bien se encuentra afiliada únicamente a un ente gestor, y le
sirve para realizar sus trámites de afiliación o reafiliación.
Según la información que se obtuvo entrevistando al personal del INASES, hay casos en
que algunas personas se encuentran afiliadas en más de un ente gestor, dichas personas no
cumplen con el artículo 14 del reglamento de afiliación, desafiliación y reafiliación vigente,
ver ANEXO E, en el cual dice lo siguiente “Las personas que tuvieran dos o más
empleadores que aporten a distintos entes gestores, deberán afiliarse al ente gestor de su
conveniencia, debiendo aportar todos sus empleadores al ente gestor elegido, previa
Resolución Administrativa emitida por el INASES”.
Por las razones ya mencionadas surge la siguiente pregunta:
¿Cómo se podrá agilizar el proceso de obtener un certificado de no afiliación a

distintos entes gestores que necesitan las personas para realizar sus trámites, con la
finalidad de acortar el tiempo que tardan en obtener la información que certifique su
estado de afiliación?
6
1.3.2 PROBLEMAS SECUNDARIOS
A continuación se mencionan los problemas identificados:
 La cantidad de beneficiarios se aproxima a los 4 millones, es por eso que el control

manual que se tiene sobre ellos es deficiente, esto ocasiona que algunas personas
están afiliadas a más de un ente gestor.
 Las personas que están afiliadas a más de un ente gestor están violando el artículo
14 del reglamento de afiliación, desafiliación y reafiliación del INASES.
 Una persona no puede consultar su pertenencia a los distintos entes gestores de
manera rápida, lo que la persona demore tiempo en sus trámites de afiliación o
reafiliación.
 No se cuenta con un sistema que integre la información de los afiliados de todos los
entes gestores en el INASES.
1.4 DEFINICIÓN DE OBJETIVOS
1.4.1 OBJETIVO GENERAL

Desarrollar un sistema web para el control y seguimiento del estado de afiliación de las
personas en los entes gestores para el Instituto Nacional de Seguros de Salud, que permita
proporcionar un certificado de no afiliación de manera rápida y eficiente.
1.4.2 OBJETIVOS ESPECÍFICOS

 Realizar un análisis de la situación actual del proceso de obtención del certificado
de no afiliación en los entes gestos.
 Determinar los procesos y las herramientas para recolectar la información y
procesar los datos para obtener el certificado de no afiliación, con el fin de cumplir
con el marco legal Boliviano vigente.
 Establecer las metodologías necesarias para diseñar los módulos y desarrollar el
sistema web.
7
 Establecer una arquitectura adecuada para distribuir la carga de los servidores
debido a que el sistema se publicara a nivel nacional.
 Diseñar los módulos que compondrán el sistema e implementar de acuerdo a las
metodologías escogidas.
 Establecer y hacer cumplir un plan de pruebas y seguridad para el sistema.
1.5 JUSTIFICACIÓN
1.5.1 ECONÓMICA
El INASES ya cuenta con los equipos, herramientas y tecnologías necesarios para la
realización del sistema web. El tiempo para conseguir la certificación de no afiliación es de
un día o más, con este sistema se podrá acortar el tiempo, ya que el sistema será vía on-line
de esta menara se obtendrá el certificado de manera más rápida. Además que el certificado
de afiliación no tendrá costo alguno.
1.5.2 SOCIAL
El sistema consolidara la información de la población recolectando la información desde
los empleadores, los cuales podrán insertar la información de sus empleados en el sistema,
el resultado de esto será tener la información integra y protegida, de la cual se podrá otorgar
el certificado de no afiliación a las personas que lo requieran.
Además los empleadores podrán generar y actualizar planillas, con la información del
sistema, estas planillas beneficiaran a los empleadores como también al INASES.
1.5.3 TÉCNICA
El uso de la tecnología es una herramienta indispensable para las empresas, instituciones o
entidades públicas y privadas, las cuales requieren manejar una gran cantidad de
información importante, para ello una institución debe contar con las herramientas y
equipos necesarios.
El INASES cuenta con 4 servidores basados en Linux y 3 laptops HP, velocidad de 2.8 ghz,
4 Gb en memoria RAM con sistema operativo Windows 7, los cuales son suficientes para el
8
desarrollo e implementación del sistema web, por eso el proyecto es técnicamente
justificable.
1.6 ALCANCES Y LÍMITES
1.6.1 ALCANCES
El presente proyecto tiene como alcances a los siguientes módulos:
 Modulo Registro.- El sistema abarcara un registro único de entes gestores, empresas
cotizantes y las personas con un identificador único.
 Modulo Consulta.- El sistema podrá generar certificados de no afiliación a los
distintos entes gestores vía online, para las personas que lo requieran.
 Modulo Planilla.- El sistema podrá generar planilla para que los empleadores
puedan actualizar la información de sus empleados, lo cual se podrá realizar vía
online. Además el módulo podrá generar reportes de las planillas terminadas.
 Modulo Control.- El sistema podrá controlar los accesos que se les da a los usuarios.
Y atender solicitudes de cambio de datos de los beneficiarios que harán los
empleadores.
 Modulo Seguridad.- El sistema contara con seguridad lógica para proteger la
información.
1.6.2 LÍMITES
El sistema web que se desarrollara tendrá los siguientes límites:
 El sistema web tendrá funcionalidad a nivel nacional, para aquellas personas que
requieran sus servicios.
 El sistema no podrá verificar que los datos que envíen los entes gestores, sean
correctos gramaticalmente.
 El sistema generara reportes de los datos que envíen los empleadores.
9
1.7 APORTES
1.7.1 TEÓRICO
Para proteger la base de datos se hará uso de la configuración Base de Datos Espejo
(Database Mirroring) donde dos o tres servidores de base de datos, ejecutándose en equipos
independientes, cooperan para mantener copias de la base de datos y archivo de registro de
transacciones (log). Se usara el método Least Connections para balancear la carga de los
servidores. Se pretende proteger al certificado de no afiliación que emitirá el sistema de
información web, con un código de barras bidimensional. Esto con el objetivo de poder
verificar que los certificados no sean plagiados, cuando se haga uso de ellos.
1.7.2 PRÁCTICO
El desarrollo del sistema traerá consigo beneficios tanto para el INASES, para las
empresas, los entes gestores y las personas residentes en Bolivia.
A continuación se mencionan algunos beneficios que se obtendrán:
 Centralizar todos los datos de todos los beneficiarios del seguro social de corto
plazo del país.
 Las personas podrán tener una certificación de no afiliación a los seguros de salud,
de forma rápida y efectiva.
 Acceso al sistema desde cualquier parte del país, a donde llegue internet.
 El INASES contará un sistema con el cual apoyará a las empresas y personas del país.
 El módulo de seguridad protegerá la información de los usuarios.
 EL INASES contara con una información actualizada sobre todos los afiliados del
país.
10
CAPITULO II
MARCO TEÓRICO
2.1 INGENIERIA DE SOFTWARE

La Ingeniería de Software (SE del inglés Software Engineering) es un enfoque sistemático
del desarrollo, operación, mantenimiento y retiro del software", que en palabras más llanas,
se considera que "la Ingeniería de Software es la rama de la ingeniería que aplica los
principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-
efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software", es
decir, "permite el elaborar consistentemente productos correctos, utilizables y costo-
efectivos". [ANGELFIRE, 2012]
El proceso de desarrollo de software "es aquel en que las necesidades del usuario son
traducidas en requerimientos de software, estos requerimientos transformados en diseño y
el diseño implementado en código, el código es probado, documentado y certificado para su
uso operativo". [ANGELFIRE, 2012]
2.1.1 METODOLOGIAS DE DESARROLLO

Las Metodologías de Desarrollo de Software surgen ante la necesidad de utilizar una serie
de procedimientos, técnicas, herramientas y soporte documental a la hora de desarrollar un
producto software. Las metodologías pretenden guiar a los desarrolladores a crear un nuevo
software, pero los requisitos de un software a otro son tan variado y cambiante, que ha dado
lugar a una gran variedad de metodologías para la creación del software. Se podrían
clasificar en dos grandes grupos:
 Las metodologías procedurales, estableciendo rigurosamente las actividades a
desarrollar, herramientas a utilizar y notaciones utilizadas. Estas metodologías
son también llamadas Metodologías Pesadas.
11
 Las metodologías dirigidas a la interactuación con el cliente y el desarrollo
incremental del software, mediante el prototipado, para que pueda evaluar y
sugerir cambios en el producto según se va desarrollando. Así llamadas
Metodologías ágiles.
Actualmente una metodología es un conjunto integrado de técnicas y métodos que permite
abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un
proyecto de desarrollo. Las metodologías se basan en una combinación de los modelos de
proceso genéricos (cascada, incremental, etc). Definen artefactos, roles y actividades, junto
con prácticas y técnicas recomendadas [PRESSMAN, 2005].
Cada una de las metodologías disponibles es más adecuada para tipos específicos de
proyectos, basados en consideraciones técnicas, organizacionales, de proyecto y de equipo.
Una metodología de desarrollo de software o metodología de desarrollo de sistemas en
ingeniería de software es un marco de trabajo que se usa para estructurar, planificar y
controlar el proceso de desarrollo de un sistema de información. [PRESSMAN, 2005].
2.1.1.1 METODOLOGIAS DE DESARROLLO AGILES

A principios de las décadas de los 90 surgió un enfoque que era revolucionario para su
momento ya que iba en contra de la creencia de que mediante procesos altamente definidos
se iba a lograr obtener software de alta calidad en un tiempo y costo determinado. El
enfoque fue planteado por primera vez en el año 1991 por James Martin, que consistía en
un entorno de desarrollo altamente productivo, en el que participaban grupos pequeños de
programadores utilizando herramientas que generaban código de forma automática
tomando como entrada sintaxis de alto nivel. En general se consideraba que este fue uno de
los primeros hitos en pos de la agilidad en los procesos de desarrollo.
Tras pasar cierto tiempo de este primer enfoque de agilidad en los procesos de desarrollo,
en febrero del 2001 se reunieron miembros prominentes de la comunidad software y
adaptaron el nombre de metodologías agiles, poco después formando la ¨Alianza Ágil¨ que
es una organización sin fines de lucro, que promueve el desarrollo ágil de aplicaciones.
12
Las metodologías agiles nacen como una reacción contra los métodos de ¨peso pasado¨,
muy estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El proceso
originado de uso del modelo en cascada era visto como burocrático, lento degradante e
inconsistente con las formas de desarrollo que realmente realizaban un trabajo eficiente.
[NUÑEZ, 2010]
Las metodologías agiles son un marco conceptual de la ingeniería de software que

promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto,
considerando una iteración como una unidad de tiempo que dura de uno a cuatro semanas.
Donde cada iteración del ciclo de vida incluye planificación, análisis, diseño, codificación,
revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para
justificar el lanzamiento del producto al mercado, pero la meta es tener un producto parcial
o una parte del todo al final de cada iteración. [LETELIER, 2006]
a) MANIFIESTO ÁGIL
[LETELIER, 2006] nos dice que el Manifiesto Ágil comienza enumerando los principales
valores del desarrollo ágil. Según el manifiesto se valora:
 Al individuo y las iteraciones del equipo de desarrollo sobre el proceso y las

herramientas. La gente es el principal factor de éxito de un proyecto de software. Es
más importante que construir un buen equipo que construir el entorno. Muchas
veces se comete el error de construir primero el entorno y esperar que el equipo se
adapte automáticamente.
 Desarrollar software que funciona más que conseguir una buena documentación. La
regla a seguir es “no producir documentos a menos que sean necesarios de forma
inmediata para tomar una decisión importante”. Estos documentos deben ser cortos
y centrarse en lo fundamental.
 La colaboración con el cliente más que la negación de un contrato. Se propone que
exista una interacción constante entre el cliente y el equipo de desarrollo. Esta
colaboración entre ambos será la que marque la marcha del proyecto y asegure su
éxito.
13
 Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, etc), determina también el éxito o fracaso
del mismo. Por lo tanto, la planificación no debe ser estricta puesto que hay muchas
variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan
surgir.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios
son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software

que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que

necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
14
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo,
y según esto ajusta su comportamiento.
b) METODOLOGÍAS AGILES VS METODOLOGÍAS TRADICIONALES
En la siguiente tabla se muestra una comparación entre las características de las

metodologías agiles frente a las tradicionales.
METODOLOGÍAS AGILES METODOLOGÍAS TRADICIONALES
La planificación del trabajo sólo comprende el ciclo Trabajo y gestión guiada por un plan general del
en el que se está trabajando (normalmente 30 días). proyecto que comprende todo su ciclo de desarrollo.
Descubrimiento progresivo de requisitos e Conocimiento detallado de los requisitos antes de

incorporación de cambios en cualquier iteración del comenzar el diseño del proyecto.
desarrollo.
“Refactorización” de código como modelo de trabajo “Hacerlo bien a la primera”. Evitar la re-codificación
compatible con el punto anterior. y el re-trabajo que supone una pérdida de eficiencia.
Comunicación directa entre los integrantes del Comunicación formal según el plan de comunicación
equipo (incluidos cliente y usuarios) prefiriendo la del proyecto.
verbal directa.
Equipos auto-gestionados. Gestión de equipos y personas centralizada en el

gestor del proyecto.
No existe contrato tradicional o al menos es bastante Existe un contrato prefijado.

flexible.
El cliente es parte del equipo de desarrollo, participa El cliente interactúa con el equipo de desarrollo
permanentemente del desarrollo. mediante reuniones, el cliente está forzado a tomar
todas las decisiones al principio.
Grupos pequeños (< 10 integrantes) y trabajando en Grupos grandes y posiblemente distribuidos.

el mismo sitio.
15
Pocos artefactos. Más artefactos.
Pocos roles. Más roles.
Menos énfasis en la arquitectura del software. La arquitectura del software es esencial y se expresa
mediante modelos.
Tabla 2.1: Metodología Ágil vs. Metodología Tradicional

Fuente: [CANOS, 2000]
Como se puede observar en la tabla las metodologías agiles se acomodan a lo que hoy en
día se requiere para desarrollar proyectos en menos tiempo y con calidad.
2.2 METODOLOGÍA DE DESARROLLO ÁGIL SCRUM
2.2.1 ¿QUÉ ES SCRUM?

Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar
al máximo la productividad de un equipo. Reduce al máximo la burocracia y actividades no
orientadas a producir software que funcione y produce resultados en periodos muy breves
de tiempo. [CITON, 2006]
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado
para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde
los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales. [ALBALADEJO, 2013]
Scrum se basa en:
 El desarrollo incremental de los requisitos del proyecto en bloques temporales

cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se
necesita).
 La priorización de los requisitos por valor para el cliente y coste de desarrollo en
cada iteración.
 El control empírico del proyecto. Por un lado, al final de cada iteración se
demuestra al cliente el resultado real obtenido, de manera que pueda tomar las
decisiones necesarias en función de lo que observa y del contexto del proyecto en
ese momento.
16
Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones
necesarias.
 La potenciación del equipo, que se compromete a entregar unos requisitos y para
ello se le otorga la autoridad necesaria para organizar su trabajo.
 El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y
conseguir resultados.
2.2.2 ROLES
Según [ALBALADEJO, 2013], los diferentes roles que define SCRUM son:
 El cliente (Product Owner).- Es el representante de todos los interesados en el

proyecto, con autoridad para tomar decisiones. Define los objetivos del producto o
proyecto y dirige los resultados del proyecto maximizando su ROI, para lo cual
participa en las reuniones de planificación de iteración y de demostración.
 El facilitador (Scrum Master).- El gestor de proyecto pasa a ser un facilitador que

vela por que se cumpla el proceso de Scrum, quita impedimentos, protege al equipo
y facilita las reuniones para que tanto el equipo como el cliente colaboren y se
obtengan las máximas sinergias.
 El equipo (Team).- Desarrolla el producto y tiene un objetivo común, dado que

adquiere un compromiso en cada iteración. Es un equipo auto-organizado y
multidisciplinar, idealmente de entre 5 y 9 personas a tiempo completo, en una
misma localización física y trabajando en un único proyecto.
2.2.3 HERRAMIENTAS Y PRÁCTICAS

Según [PERALTA, 2003], las herramientas y prácticas que SCRUM nos proporciona son:
 Lista de objetivos/requisitos priorizada (Product Backlog).- Es una lista

priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un
proyecto comienza es muy difícil tener claro todos los requerimientos sobre el
producto. Sin embargo, suelen surgir los más importantes que casi siempre son más
17
que suficientes para un Sprint. La Product Backlog puede crecer y modificarse a
medida que se obtiene más conocimiento acerca del producto y del cliente. Con la
restricción de que solo puede cambiarse entre Sprints.
El objetivo es asegurar que el producto definido al terminar la lista es el más

correcto, útil y competitivo posible y para esto la lista debe acompañar los cambios
en el entorno y el producto.
 Lista de tareas de la iteración (Sprint Backlog).- Es el punto de entrada de cada

Sprint. Es una lista que tiene los ítems de la Product Backlog que van a ser
implementados en el siguiente Sprint. Los ítems son seleccionados por el Scrum
Team, el Scrum Master y el Product Owner en la Sprint Planning Meeting a partir
de la priorización de los ítems y los objetivos que se marcaron para ese Sprint. A
partir de los objetivos a cumplir durante el Sprint el Scrum Team determina que
tareas debe desempeñar para cumplir el objetivo. De esto surge el Sprint Backlog.
Es importante destacar que es el equipo quien se organiza para alcanzar el objetivo.
El Manager no asigna tareas a los individuos y tampoco toma decisiones por el
equipo. El equipo puede agregar nuevas tareas o remover tareas innecesarias en
cualquier momento si lo considera necesario para cumplir el objetivo. Pero el Sprint
Backlog solo puede ser modificado por el equipo. Las estimaciones se actualizan
cada vez que aparece nueva información.
 Gráficos de trabajo pendiente (Burndown charts).- En Scrum se planifica y mide

el esfuerzo restante necesario para desarrollar el producto. Esta gráfica suele
utilizarse en lugar de un diagrama de PERT debido a que el camino crítico en un
desarrollo ágil cambia diariamente. Esto haría obsoleto el diagrama de PERT cada
día. Es por esto que no es útil una herramienta que modele el camino crítico a partir
de actividades. La solución es utilizar una técnica que permita medir la velocidad de
desarrollo. Para esto se utiliza el criterio del equipo a partir del cual se calcula
diariamente el camino crítico. Esto permite recalcular el plan y la velocidad en que
se realiza el trabajo. En
18
función de esto el equipo puede trabajar para acelerar o desacelerar el trabajo para
cumplir con la fecha de entrega.
 Sprint.- Un Sprint es el procedimiento de adaptación de las cambiantes variables

del entorno (requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos
iterativos en los cuales se desarrolla o mejora una funcionalidad para producir
nuevos incrementos. Durante un Sprint el producto es diseñado, codificado y
probado. Y su arquitectura y diseño evolucionan durante el desarrollo. El objetivo
de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y
esté siempre presente en el equipo. Es posible definir una serie de restricciones que
el equipo deba aplicar durante un Sprint. Un Sprint tiene una duración planificada
de entre una semana y un mes.
2.2.4 FASES DEL SCRUM

Scrum es una metodología ágil fácil de comprender, las fases que comprende SCRUM son:
pre-juego, juego o desarrollo y post-juego.
Figura 2.1: Fases del SCRUM.

Fuente: [GALIANO, 2012]
19
2.2.4.1 PRE JUEGO (PRE GAME)
Según [PERALTA, 2003], la fase de Pregame incluye dos subfases: Planning y Architecture.
 Planning.- Consiste en la definición del sistema que será construido. Para esto se
crea la lista Product Backlog a partir del conocimiento que actualmente se tiene del
sistema. En ella se expresan los requerimientos priorizados y a partir de ella se
estima el esfuerzo requerido. La Product Backlog List es actualizada
constantemente con ítems nuevos y más detallados, con estimaciones más precisas
y cambios en la prioridad de los ítems.
 Architecture / High level Design El diseño de alto nivel del sistema se planifica a
partir de los elementos existentes en la Product Backlog. En caso de que el
producto a construir sea una mejora a un sistema ya existente, se identifican los
cambios necesarios para implementar los elementos que aparecen en la lista
Product Backlog y el impacto que pueden tener estos cambios.
Se parte de la concepción inicial del producto que tiene el cliente, luego realizar las tareas
que se especifican en la tabla xx, y posteriormente verificar que las tareas estén realizadas,
para tener como resultado final de esta fase el Product Backlog y la arquitectura.
Nombre de la Requerida/
Descripción Responsables
tarea Opcional
Posibles elementos de esta lista son requerimientos
Crear la Product técnicos y del negocio, funciones, errores a reparar, Product
Backlog List y defectos, mejoras y actualizaciones tecnológicas Owner
Requerida
controlar su requeridas. Es importante controlar la consistencia se Scrum
consistencia de la lista. Para esto se agregan, modifican, eliminan, Master
especifican y priorizan sus elementos
Esta actividad se basa en considerar que elementos Product
Priorizar la
tienen más o menos influencia en el éxito del proyecto Owner
Product Backlog Requerida
en un momento dado; considerando que los elementos Scrum
List
con mayor prioridad se realizan primero. Master
20
Es un proceso iterativo que reúne toda la información
Product
que haya acerca un elemento para tener un mayor
Owner
nivel de precisión en la estimación. Siempre se mide
Effort Estimation Scrum Requerida
el esfuerzo que falta para cumplir con el / los objetivos
Master
tanto a nivel de la lista Product Backlog como para el
Scrum Team
Sprint Backlog (lo que resta).
En esta instancia se comunica el diseño a los
Design Review
interesados para revisar el cumplimiento de los ítems Requerida
Meeting
especificados en el Product Backlog
Tabla 2.2: Tareas de la fase Pre-juego
Fuente [PERALTA, 2003]
2.2.4.2 JUEGO (GAME)
La fase de juego también llamada desarrollo es la parte en que se espera que ocurran cosas
impredecibles. Para evitar el caos Scrum define prácticas para observar y controlar las
variables técnicas y del entorno, así también como la metodología de desarrollo que hayan
sido identificadas y puedan cambiar. Este control se realiza durante los Sprints. Dentro de
variables de entorno encontramos: tiempo, calidad, requerimientos, recursos, tecnologías y
herramientas de implementación. Scrum propone controlarlas constantemente para poder
adaptarse a los cambios en forma flexible.
Planificación de la iteración (Sprint Planning)
La planificación de las tareas a realizar en la iteración se divide en dos partes:
Primero se realiza en un timebox de máximo 4 horas :
El cliente presenta al equipo la lista de requisitos priorizada del proyecto y propone los requisitos más
prioritarios a desarrollar en ella.
El equipo pregunta al cliente las dudas que le surgen, añade más condiciones de satisfacción y selecciona
los requisitos más prioritarios que se compromete a completar en la iteración.
Segundo el equipo planifica la iteración. Esto se realiza en un timebox de máximo 4 horas.
Define las tareas necesarias para poder completar cada objetivo, creando la lista de tareas de la iteración
(Sprint Backlog)
Cada miembro del equipo se autoasignan a las tareas que puede realizar.
21
Desarrollo de la iteración (Sprint)
Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea
potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario
un esfuerzo mínimo para que el producto esté disponible para ser utilizado.
Cada día el equipo realiza una reunión diaria de sincronización (Scrum Daily meeting), que dura 15
minutos máximo, donde cada miembro inspecciona el trabajo de los otros para poder hacer las
adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado
de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).
En la reunión cada miembro del equipo responde las siguientes preguntas: ¿Qué he hecho desde la última
reunión? ¿Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema? ¿Qué voy a hacer a partir de este
momento? ¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteración y en el
proyecto?
El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no
se merme su productividad.
Elimina los obstáculos que el equipo no puede resolver por sí mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.
Prueba (Sprint Review y Sprint Retrospective)
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:
Demostración de requisitos completados (Sprint Review) en 4 horas máximo. El equipo presenta al cliente
los requisitos completados en la iteración, en forma de incremento de producto preparado para ser
entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya
habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya
desde la primera iteración, replanificando el proyecto.
Retrospectiva (Sprint Retrospective) en 4 horas máximo. El equipo analiza cómo ha sido su manera de
trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera
continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.
Replanificación del proyecto – Product Backlog Refinement
En las reuniones de planificación de entregas y durante el transcurso de una iteración el cliente va

trabajando en la lista de objetivos/requisitos priorizada del proyecto, añadiendo requisitos, modificándolos,
22
eliminándolos, repriorizándolos, cambiando el contenido de iteraciones y definiendo un calendario de
entregas que se ajuste mejor a sus nuevas necesidades, esta puede ser presentada solamente en la
planificación de una iteración.
Los cambios en la lista de requisitos pueden ser debidos a:
Modificaciones que el cliente solicita tras la demostración que el equipo realiza al final de cada iteración
sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto.
Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a
urgencias o nuevas peticiones de clientes, etc).
Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
Para realizar esta tarea, el cliente colabora con el equipo:
Para cada nuevo objetivo/requisito, conjuntamente se hace una identificación inicial de sus condiciones de
satisfacción (que se detallarán en la reunión de planificación de la iteración).
El cliente obtiene del equipo la re-estimación de costes de desarrollo para completar los
objetivos/requisitos siguientes, según la definición de completado. El equipo ajusta el factor de
complejidad, el coste para completar los requisitos y su velocidad de desarrollo en función de la
experiencia adquirida hasta ese momento en el proyecto.
El cliente re-prioriza la lista de objetivos/requisitos en función de estas nuevas estimaciones.
Tabla 2.3: Actividades de SCRUM

Fuente: [ALBALADEJO, 2013]
2.2.4.3 POST JUEGO (POST GAME)
Contiene el cierre del release. Para ingresar a esta fase se debe llegar a un acuerdo respecto
a las variables del entorno por ejemplo que los requerimientos fueron completados. El
sistema está listo para ser liberado y es en esta etapa en la que se realiza integración,
pruebas del sistema y documentación.
2.3 ARQUITECTURA DE SOFTWARE
2.3.1 ARQUITECTURA 3 CAPAS

La programación por capas es una arquitectura cliente-servidor en el que el objetivo
primordial es la separación de la lógica de negocios de la lógica de diseño. En dichas
arquitecturas a cada capa se le confía una misión simple, lo que permite el diseño de
23
arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades
aumenten). [LÓPEZ, 2009]
Según [LÓPEZ, 2009], en la arquitectura 3 capas, se cuenta con las siguientes capas:
 Capa de presentación: es la que ve el usuario (también se la denomina "capa de

usuario"), presenta el sistema al usuario, le comunica la información y captura la
información del usuario en un mínimo de proceso (realiza un filtrado previo para
comprobar que no hay errores de formato). También es conocida como interfaz
gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar)
para el usuario. Esta capa se comunica únicamente con la capa de negocio.
 Capa de negocio: es donde residen los programas que se ejecutan, se reciben las
peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa
de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen
todas las reglas que deben cumplirse. Esta capa se comunica con la capa de
presentación, para recibir las solicitudes y presentar los resultados, y con la capa de
datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él..
 Capa de datos: es donde residen los datos y es la encargada de acceder a los

mismos. Está formada por uno o más gestores de bases de datos que realizan todo el
almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de
información desde la capa de negocio.
En la siguiente figura podemos ver la arquitectura tres capas.
Figura 2.2: Arquitectura 3 capas

Fuente: [LÓPEZ, 2009]
24
2.3.2 BALANCEO DE CARGA EN LOS SERVIDORES
El balanceo de carga se refiere a los métodos que existen para distribuir el trabajo que tiene
un servidor en dos o más servidores al momento de atender las peticiones de los clientes.
Dando de esta manera más rapidez en las respuestas hacia los clientes y evitando que haya
sobrecarga de trabajo en un servidor.
Existen muchos métodos de balanceo de carga, en el presente proyecto se hará uso del
método LEAST CONNECTIONS (Menos conexiones) el cual según [TENNESSEE, 2015],
nos indica que un nodo debe distribuir y hacer una nueva conexión cliente/servidor con el
nodo que tiene el menor número de conexiones activas.
2.3.3 BASE DE DATOS ESPEJO

Una base de datos espejo o reflejo es una solución de software principalmente para
aumentar la disponibilidad de una base de datos. Una base de datos espejo mantiene dos
copias de una sola base de datos que deben residir en diferentes instancias de servidor.
Normalmente, estas instancias de servidor residen en las computadoras en diferentes
lugares.
Una instancia del servidor de la base de datos sirve a los clientes (el servidor principal). El
otro caso actúa como un servidor de reserva (el servidor espejo), dependiendo de la
configuración y el estado de la sesión de la creación del espejo.
Cuando se sincroniza la sesión de la base de datos espejo, la base de datos espejo

proporciona reserva que soporta conmutación por error rápida y sin pérdida de datos de
transacciones comprometidas.
Cuando la sesión no está sincronizado, el servidor espejo está disponible como un servidor
de reserva (con posible pérdida de datos). [MICROSOFT, 2008]
2.4 INGENIERÍA WEB

En la ingeniería de software se hace referencia a técnicas, herramientas y metodologías para
el desarrollo de un software de calidad. De ahí que para desarrollar una aplicación web este
como software debe pasar por una serie de fases, para que el producto final sea de calidad.
25
La ingeniería web es el proceso con el que se crean las WebApps de alta calidad. La
Ingeniería Web no es un clon perfecto de la ingeniería de software, pero utiliza muchos
conceptos y principios fundamentales de ella. [GARCIA, 2013].
2.4.1 APLICACIÓN WEB

Aplicación web (web-based application) es un tipo especial de aplicación cliente/servidor,
donde tanto el cliente (el navegador, explorador o visualizador) como el servidor (el
servidor web) y el protocolo mediante el que se comunican (HyperText Transfer Protocol
(HTTP)) están estandarizados y no han de ser creados por el programador de aplicaciones
(Figura 2.1). [LUJAN, 2001]
Figura 2.3: Esquema básico de una aplicación web

Fuente: [LUJAN, 2001]
El cliente web es un programa con el que interacciona el usuario para solicitar a un servidor
web el envío de los recursos que desea obtener mediante HTTP. El servidor web es un
programa que está esperando permanentemente las solicitudes de conexión mediante el
protocolo HTTP por parte de los clientes web. [LUJAN, 2001]
Una aplicación web es un software que provee servicios web, a los cuales los usuarios
pueden acceder a través de internet con un navegador.
Según [LUJAN, 2001] las aplicaciones web tiene las siguientes ventajas:
 Las actualizaciones cambios se hacen solo en el servidor web.

 Versionamiento del software es igual para todos los usuarios.
 Ahorro de costos porque una aplicación web solo necesita internet para funcionar.
26
 Una aplicación web se puede ejecutar en distintas plataformas (hardware y sistema
operativo).
2.4.2 SEGURIDAD INFORMATICA

Según [JEREZ, 2004] la seguridad informática es el conjunto de procedimientos,
estrategias y herramientas que permitan garantizar la integridad, la disponibilidad y la
confidencialidad de la información de una entidad.
En este sentido integridad se refiere a asegurar que los datos no sufran cambios no
autorizados, disponibilidad a la continuidad operativa de la entidad, y la confidencialidad se
refiere a la protección de datos frente a la difusión no autorizada.
2.4.2.1 SEGURIDAD LOGICA

La informacion en general es un activo muy importante para las empresas, por ello mismo
esta debe ser confidencial y ser accesible para personas que tengan los permisos.
La seguridad logica consiste en la aplicación de barreras y procedimientos que resguarden

el acceso a los datos y solo se permita acceder a ellos a las personas autorizadas para
hacerlo. [BORGHELLO, 2001]
Según [BORGHELLO, 2001], los objetivos que se plantea la seguridad logica son:
 Restringir el acceso a los programas y archivos.
 Asegurar que los operadores puedan trabajar sin una supervisión minuciosa y no
puedan modificar los programas ni los archivos que no correspondan.
 Asegurar que sean utilizados los datos, archivos y programas correctos en y por el
procedimiento correcto.
 Que la información recibida se la misma que ha sido transmitida.
 Que existan sistemas alternativos secundarios de transmisión entre diferentes puntos.
27
 Que se disponga de pasos alternativos de emergencia para la transmisión de
información.
Según [ROMERO, 2011], las prácticas básicas al desarrollar una aplicación web deben ser:
a) Balancear Riesgo y Usabilidad

Si bien la usabilidad y la seguridad en una aplicación web no son necesariamente
mutuamente excluyentes, algunas medidas tomadas para incrementar la seguridad con
frecuencia afectan la usabilidad. Al igual que debemos pensar en las maneras en que
usuarios ilegítimos nos pueden atacar, también debemos considerar la facilidad de uso
para los usuarios legítimos.
La recomendación inicial sería tratar de usar medidas de seguridad que sean
transparentes a los usuarios. Por ejemplo, la solicitud de un nombre de usuario y una
contraseña para registrarse en un sistema son procedimientos esperados y lógicos por
parte del usuario.
b) Rastrear el paso de los Datos
La medida más importante como desarrollador preocupado por la seguridad que
podemos tomar es mantener conocimiento de los pasos que ha recorrido la información
en todo momento. Conocer de dónde vinieron los datos y hacia dónde van. En muchas
ocasiones lograr esto puede ser complicado, especialmente sin un conocimiento
profundo de cómo funcionan los sistemas Web.
En las aplicaciones web, existen maneras de distinguir los orígenes de los datos y poder
así reconocer cuando los datos pueden ser dignos de confianza y cuando no. Ante todo,
debemos recordar que la desesperación y la paranoia con mucha frecuencia nos dirigen
a complicaciones y errores.
c) Filtrar Entradas
El filtrado es una de las piedras angulares de la seguridad en aplicaciones web. Es el
proceso por el cual se prueba la validez de los datos. Si nos aseguramos que los datos
son filtrados apropiadamente al entrar, podemos eliminar el riesgo de que datos
contaminados y que reciben confianza indebida sean usados para provocar
funcionamientos no deseados en la aplicación.
28
El proceso de filtrado debe estar conformado por los siguientes pasos:
 Identificar la entrada.
 Filtrado de la entrada.
 Distinguir entre datos que ya han pasado por el filtro y los que no.
Por lo general, se considera más seguro tratar a los datos provenientes de bases de datos
como entradas, aunque supuestamente sean bases seguras y en las que debiéramos tener
confianza, esto se debe a que es mejor tener redundancia para evitar problemas en el
caso de que la base de datos fuera vulnerada.
Al usar listas blancas asumimos que los datos son inválidos a menos que prueben ser
validos al encontrarse patrones coincidentes en la lista blanca. Una limitante de usar
este punto de vista es considerar inválidos datos que debieron considerarse válidos pero
que no fueron tomados en cuenta patrones similares al construir la lista blanca.
Una vez concluido el paso del filtrado solo resta usar convenciones apropiadas en el
nombramiento de las variables para poder distinguir las que ya han sido filtradas. Una
recomendación sería guardar las variables que ya hayan sido filtradas en un arreglo de
fácil identificación (como $limpio).
d) Encriptación
Encriptación es el proceso mediante el cual cierta información o texto sin formato es
cifrado de forma que el resultado sea ilegible a menos que se conozcan los datos
necesarios para su interpretación. Es una medida de seguridad utilizada para que al
momento de almacenar o transmitir información sensible ésta no pueda ser obtenida con
facilidad por terceros. Opcionalmente puede existir además un proceso de
desencriptación a través del cual la información puede ser interpretada de nuevo a su
estado original, aunque existen métodos de encriptación que no pueden ser revertidos.
La encriptación MD5 (abreviatura de Message-Digest Algorithm 5, Algoritmo de
Resumen del Mensaje 5) es un algoritmo de reducción criptográfico de 128 bits
ampliamente usado.
29
2.5 UWE
2.5.1 ¿QUÉ ES UWE?

Según [LMU, 2000], UWE (UML-Based Web Engineering) es un método de ingeniería del
software para el desarrollo de aplicaciones web basado en UML (Unified Modeling
Language en español Lenguaje Unificado de Modelado). El enfoque UWE proporciona una
notación de dominio específico, un proceso de desarrollo dirigido por modelos, y el apoyo
de herramientas para la ingeniería de aplicaciones Web.
UWE utiliza notación UML pura y tipos de diagramas UML siempre que sea posible para
el análisis y diseño de aplicaciones Web. Por las características de la Web, como nodos y
enlaces de la estructura de hipertexto, el perfil UWE incluye estereotipos, valores
etiquetados y restricciones definidas para los elementos de modelado. UWE cubre la
navegación, la presentación, los procesos de negocio y los aspectos de adaptación. La
notación UWE se define como una extensión "ligero" del UML. La característica de UWE
es el hecho de que es un enfoque basado en estándares que no se limita al uso de UML.
[LMU, 2000]
2.5.2 MODELOS
Según [LMU, 2000], en los modelos de UWE se hace uso de los siguientes diagramas:
 Diagrama de Casos de Uso.- Un caso de uso es una descripción de las acciones de

un sistema desde el punto de vista del usuario.
 Diagrama de clases.- Una clase es una categoría o grupo de cosas que tienen
atributos y acciones similares.
En UWE tenemos muchos modelos para detallar aspectos del sistema web pero los modelos
más importantes que comprende UWE y los que en el presente proyecto se aplicaran son el
modelo de requisitos, modelo de contenido, modelo de navegación y modelo de
presentación.
2.5.2.1 MODELO DE REQUISITOS

En UWE el modelado requisitos consta de dos partes:
30
 Los casos de uso de la aplicación y sus relaciones
 Actividades que describen casos de uso en detalle
En el presente proyecto solo se harán los casos de uso de la aplicación y sus relaciones, ya
que son suficientes para el entendimiento del cliente.
En UWE los Casos de Uso se distinguen por los estereotipos <<processing>> y

<<browsing>> para indicar si una aplicación modifica o no los datos persistentes de la
aplicación. En la siguiente figura se muestra los iconos para cada estereotipo:
Figura 2.4: Iconos de los estereotipos para el diagrama de casos de uso

Fuente: [LMU, 2000]
Y en la siguiente tabla se muestra el uso de cada estereotipo:
Estereotipo Uso
<<Processing>> Indica modificación de datos.
<<Browsing>> indica lo contrario a processing

Tabla 2.4: Estereotipos para el diagrama de casos de uso
Fuente: [LMU, 2000]
En la siguiente figura se puede observar un ejemplo de diagrama de casos de uso.
Figura 2.5: Ejemplo de diagrama de casos de uso

Fuente: [LMU, 2000]
31
2.5.2.2 MODELO DE CONTENIDO
Es un diagrama normal de clases UML, se debe pensar que clases son necesarios para el
modelo de requerimientos. En la figura 2.6 se puede observar un ejemplo de diagrama de
contenido, que va acorde al ejemplo del modelo de requisitos.
Figura 2.6: Ejemplo de diagrama de contenido

Fuente: [LMU, 2000]
2.5.2.3 MODELO DE NAVEGACIÓN
En un sistema de páginas web sería bueno saber cómo están unidas entre sí. UWE lo
soluciona con un diagrama que contiene nodos y enlaces. Pero, ¿qué es un nodo? Los nodos
son unidades de navegación conectados a través de enlaces. Los nodos se pueden mostrar
en diferentes páginas o en la misma página.
El modelo de Navegación proporcionara un diagrama que es el resultado de la

transformación del modelo de contenido y modelo de requisitos.
En la siguiente figura se muestra los iconos para cada estereotipo:
Figura 2.7: Iconos de los estereotipos para el diagrama de navegación

Fuente: [LMU, 2000]
32
Estereotipo Uso
<<navigationClass>> Representa nodo de navegación.
<<menu>> Representa el menú de navegación.
<<index>> Usado para listar una cantidad de objetos del mismo tipo.
<<query>> Recupera el contenido de una fuente de datos.
<<guidedTour>> Es un proceso secuencial a instancias de un nodo de navegación.
<<processClass>> Se utilizan para integrar los procesos de negocio en el modelo de navegación y para
definir los datos que se intercambia con el usuario durante el proceso.
<<navigationLink>> Representa el enlace entre dos nodos de navegación
<<processLink>> Asociaciones salientes y dirigidas para prohibir la navegación hacia atrás.
Tabla 2.5: Estereotipos para el diagrama de navegación

Fuente: [LMU, 2000]
En la figura 2.8 se puede observar un ejemplo de diagrama de navegación, que va acorde al
ejemplo del modelo de requisitos y contenido.
Figura 2.8: Ejemplo de diagrama de navegación

Fuente: [LMU, 2000]
33
2.5.2.4 MODELO DE PRESENTACIÓN
El modelo de navegación no muestra que la navegación y las clases de procesos pertenecen
a qué parte de la página web. Podemos utilizar un diagrama de presentación con el fin de
proporcionar esta información. En la siguiente figura se muestra los iconos para cada
estereotipo:
Figura 2.8: Iconos de los estereotipos para el diagrama de presentación

Fuente: [LMU, 2000]
Estereotipo Uso
<<presentationGroup>> Representa un conjunto de elementos que tienen algo en común.
<<presentationPage>> Representa una página.
<<text>> Representa un texto en la interfaz
<<textInput>> Representa un campo de entrada de un formulario
<<anchor>> Representa un enlace el cual se puede para navegar.
<<fileUpload>> Representa un campo en el cual se puede subir archivos al Sistema web.
<<button>> Representa un botón el cual realiza una acción al activarse.
<<image>> Representa una imagen.
<<inputForm>> Representa un conjunto de elementos que componen a un formulario.
<<customComponent>> Elemento que se puede configurar.
<<presentationAlternatives>> Nos indica que ese conjunto de elementos puede visualizarse de diferentes
maneras.
<<selection>> Representa un conjunto de opciones del cual se pueden seleccionar uno o

más valores.
Tabla 2.5: Estereotipos para el diagrama de presentación
Fuente: [LMU, 2000]
34
En la figura 2.9 se puede observar un ejemplo de diagrama de presentación, que va acorde
al ejemplo del modelo de requisitos, modelo de contenido y modelo de navegación que se
mencionaron anteriormente.
Figura 2.9: Ejemplo de diagrama de presentación

Fuente: [LMU, 2000]
2.6 BASES DE DATOS

Según [IBM, 2013] una base de datos relacional es una base de datos en la que todos los
datos se contienen lógicamente en tablas. Estas bases de datos se organizan de acuerdo al
modelo relacional.
Según [CAMPS, 2005] una base de datos de un sistema de información es la representación

integrada de los conjuntos de entidades instancia correspondientes a las diferentes entidades
tipo del sistema de información y de sus interrelaciones. Esta representación informática (o
conjunto estructurado de datos) debe poder ser utilizada de forma compartida por muchos
usuarios de distintos tipos.
Por lo tanto en otras palabras podemos decir que una base de datos es un conjunto
estructurado de datos que representa entidades y sus interrelaciones.
35
2.6.1 DESNORMALIZACIÓN
Las reglas de normalización no consideran el rendimiento. En algunos casos, es necesario
considerar la desnormalización para mejorar el rendimiento. La normalización de tablas es
la propuesta que se suele recomendar. Pero ¿qué sucede si las aplicaciones necesitan
informaciones sobre componentes y almacenes, incluidas las direcciones de los almacenes?
La premisa de las reglas de normalización es que las sentencias de SQL pueden recuperar la
información uniendo las dos tablas. El problema es que, en algunos casos, se pueden
producir problemas de rendimiento como resultado de una normalización. Por ejemplo,
algunas consultas de usuario pueden ver datos que están en una o más tablas relacionadas;
el resultado es demasiadas uniones. A medida que crece el número de tablas, los costes de
acceso pueden aumentar, según el tamaño de las tablas, los índices disponibles, etc. Por
ejemplo, si no hay índices disponibles, la unión de numerosas tablas grandes puede tardar
demasiado tiempo. Puede que necesite desnormalizar las tablas. La desnormalización es la
duplicación intencionada de columnas en varias tablas y esto aumenta la redundancia de
datos. [IBM, 2013]
Algunas ventajas que se obtienen de este proceso:
 La Desnormalización nos ayuda a mejorar el rendimiento.

 Menor número de tablas.
 Redundancia de Datos.
 Mejora Velocidad de las consultas.
 Menor Integridad de datos.
2.7 TECNOLOGIAS WEB

Una tecnología web es una tecnología que utiliza todas las tecnologías de inter conectividad
de ordenadores que permite a los usuarios el intercambio, en formato de hipertexto, de todo
tipo de datos e información (Texto, imágenes, sonido) y de aplicaciones de software.
[SONCCO, 2008]
36
2.7.1 PHP
Según [W3SCHOOLS, 2015], PHP es un acrónimo de "Hypertext Preprocessor", PHP es
un lenguaje de programación de código abierto ampliamente utilizado, que se ejecuta en el
lado del servidor, es libre para descargar y utilizar. Es lo suficientemente potente como para
estar en el centro del sistema de blogs más grande en la web (WordPress), es lo
suficientemente profundo como para ejecutar la mayor red social (Facebook), y también es
bastante fácil de ser primer lenguaje del lado del servidor de un principiante. Con PHP se
puede crear, abrir, leer, escribir, borrar y cerrar archivos en el servidor. Además de generar
páginas con contenidos dinámicos, recopilar datos de formularios, enviar y recibir cookies,
cifrar datos, controlar el acceso de usuario. Y Añadir, borrar, modificar los datos de su base
de datos
PHP se ejecuta en varias plataformas (Windows, Linux, Unix, Mac OS X, etc.), es

compatible con casi todos los servidores utilizados en la actualidad (Apache, IIS, etc.),
soporta una amplia gama de bases de datos, es libre se puede descargar desde la página
oficial y es fácil de aprender.
Un archivo PHP tiene la extensión “.php”, puede contener texto, HTML, CSS, JavaScript y
código PHP. El Código PHP se ejecuta en el lado del servidor y el resultado se devuelve al
navegador como HTML.
2.7.2 FRAMEWORK YII2

Según [YII, 2015], Yii es un framework de desarrollo de aplicaciones web libre, de código
abierto basado en PHP5, mejora el diseño y anima a un rápido desarrollo. Yii es un
framework de alto rendimiento basado en componentes para desarrollar rápidamente
aplicaciones web modernas. El nombre Yii (pronunciado Yee o [ji:]) significa "simple y
evolutivo" en chino. También puede ser pensado como un acrónimo de Yes It Is!.
La versión 2.0 es una reescritura completa de Yii, la adopción de las últimas tecnologías y
protocolos, incluyendo Composer, PSR, espacios de nombres, rasgos, y más características.
La versión 2.0 representa la generación actual del framework y recibirá los principales
esfuerzos de desarrollo en los próximos años.
37
Yii es un framework de programación Web genérico, lo que significa que se puede utilizar
para el desarrollo de todo tipo de aplicaciones web con PHP. Debido a su arquitectura
basada en componentes y soporte de almacenamiento en caché sofisticada, es
especialmente adecuado para el desarrollo de aplicaciones a gran escala, tales como
portales, foros, sistemas de gestión de contenidos (CMS), proyectos de comercio
electrónico, servicios web, y otros.
Como la mayoría de los marcos de PHP, Yii implementa el MVC (Modelo-Vista-

Controlador) patrón arquitectónico y promueve la organización del código basado en ese
patrón. Yii tiene la filosofía de que el código debe ser escrito de una manera sencilla pero
elegante. Yii es un completo framework que proporciona muchas herramientas para su uso
dispone de constructores de consulta, ActiveRecord para bases de datos relacionales y
NoSQL, seguridad contra inyecciones u otro tipo de ataques, soporte de almacenamiento en
caché de varios niveles y más.
Yii es extremadamente extensible, se puuede personalizar o cambiar casi cada pieza de

código del núcleo. También puede tomar ventaja de la arquitectura de extensión sólida de
Yii utilizando o desarrollando extensiones redistribuibles.
2.7.3 BOOTSTRAP
Según [W3SCHOOLS, 2015], Bootstrap fue desarrollado por Mark Otto y Jacob Thornton
en Twitter, y lanzado como un producto de código abierto en agosto de 2011 en GitHub.
Bootstrap es un framework para desarrollar código HTML y CSS más rápido y fácil en el
front-end (lado del cliente) de las páginas web. Bootstrap incluye plantillas HTML y CSS
para el diseño, las plantillas tienen código reutilizable para las caracterizas más importantes
de un sitio web como ser la tipografía, los formularios, los botones, las tablas, los enlaces,
los modales, carruseles de imágenes y muchas otras, así como plugins de JavaScript
opcionales.
Con Bootstrap el diseño web es Responsive, es decir se puede diseñar sitios web que se
ajusten automáticamente a sí mismos para que se visualicen bien en todos los dispositivos,
como Smart phones (celulares), tablets, laptops y ordenadores de escritorio. Además
38
bootstrap es compatible con todos los navegadores modernos (Chrome, Firefox, Internet
Explorer, Safari y Opera). Y se puede descargar libremente desde su pagina oficial.
2.7.4 APACHE
El servidor HTTP Apache es un servidor web HTTP de código abierto, para
plataformas Unix (BSD, GNU/Linux, etc.),Microsoft Windows, Macintosh y otras, que
implementa el protocolo HTTP y la noción de sitio virtual. El desarrollo del servidor HTTP
Apache se fundamenta en el trabajo de un reducido grupo de desarrolladores denominado
Apache Group. El Apache Group lo constituyen aquellos desarrolladores que han
colaborado durante un periodo prolongado de tiempo, generalmente más de seis meses.
Sobre el Apache Group recae la responsabilidad de la evolución del servidor web y, por
tanto, las decisiones puntuales de desarrollo en cada momento.
Apache es usado primariamente para enviar páginas web estáticas y dinámicas en la World
Wide Web. Muchas aplicaciones web están diseñadas asumiendo como ambiente de
implantación a Apache, o que utilizarán características propias de este servidor web.
Apache tiene amplia aceptación en la red: desde 1996, Apache, es el servidor HTTP más
usado. Alcanzó su máxima cuota de mercado en 2005 siendo el servidor empleado en el
70% de los sitios web en el mundo, sin embargo ha sufrido un descenso en su cuota de
mercado en los últimos años. (Estadísticas históricas y de uso diario proporcionadas por
Netcraft).
Este servidor web es redistribuido como parte de varios paquetes propietarios de software,
incluyendo la base de datos Oracle y el IBM WebSphere application server. Mac OS X
integra apache como parte de su propio servidor web y como soporte de su servidor de
aplicaciones WebObjects. Es soportado de alguna manera porBorland en las herramientas
de desarrollo Kylix y Delphi. Apache es incluido con Novell NetWare, donde es el servidor
web por defecto, y en muchas distribuciones Linux.
Apache es usado para muchas otras tareas donde el contenido necesita ser puesto a
disposición en una forma segura y confiable. Un ejemplo es al momento de compartir
archivos desde una computadora personal hacia Internet. Un usuario que tiene Apache
39
instalado en su escritorio puede colocar arbitrariamente archivos en la raíz de documentos
de Apache, desde donde pueden ser compartidos.
Microsoft Internet Information Services (IIS) es el principal competidor de Apache, así

como Sun Java System Web Server de Sun Microsystems y un anfitrión de otras
aplicaciones como Zeus Web Server. Algunos de los más grandes sitios web del mundo
están ejecutándose sobre Apache. La capa frontal (front end) del motor de búsqueda Google
está basado en una versión modificada de Apache, denominada Google Web Server
(GWS). Muchos proyectos de Wikimedia también se ejecutan sobre servidores web
Apache. [ECURED, 2015]
2.7.5 MARIADB
Según [MARIADB, 2015], MariaDB es un sistema de gestión de bases de datos derivado
de MySQL con licencia GPL. Está desarrollado por Michael Widenius (fundador
de MySQL) y la comunidad de desarrolladores de software libre. Introduce dos motores de
almacenamiento nuevos, uno llamado Aria que reemplaza con ventajas a MyISAM y otro
llamado XtraDB en sustitución de InnoDB. Tiene una alta compatibilidad con MySQL ya
que posee las mismas órdenes, interfaces, APIs y bibliotecas, siendo su objetivo poder
cambiar un servidor por otro directamente.
Según [WEBARCHIVE, 2015], el objetivo de MariaDB es ser un reemplazo directo de

MySQL. Este objetivo permite una compatibilidad binaria prácticamente total, al punto de
poder compartir con MySQL los archivos de definición de tablas y datos (.frm), los
conectores (sean de PHP, Perl, Python, Java, etc) y hasta poder usar el cliente mysql-client.
Las actualizaciones de MariaDB se generan mensualmente ya que el equipo de desarrollo

incorpora al código con dicha periodicidad los avances de Oracle en MySQL. Se respeta la
linealidad de versiones, así MariaDB 5.5.1 es el equivalente de MySQL 5.5.1. La única
salvedad corresponde a las versiones 5.2 y 5.3 que están basadas en MySQL 5.1 (por que
no existen versiones 5.2 y 5.3 de MySQL ya que pasaron directamente de la 5.1 a la 5.5).
40
Los beneficios de MariaDB sobre MySQL son notables, a continuación se enumera los más
importantes:
 Soporte para otros motores de almacenamiento: Aria, XtraDB, PBXT, FederatedX,

OQGraph, SphinxSE y IBMDB2I. El más destacado Aria cuyo propósito es
reemplazar a MyISAM, propósito por demás interesante considerando que Aria
puede funcionar tanto como un motor de almacenamiento transaccional como no
transaccional. La funcionalidad de Aria crece constantemente y con muy buenos
resultados.
 Optimizaciones de velocidad que incluyen: algoritmos mejorados de cheksum,
cambios en los mecanismos de conversión de caracteres, el uso de Aria para tablas
temporales, mejoras en la implementación de subconsultas, etc.
 Nueva funcionalidad como pools de threads, columnas virtuales, columnas
dinámicas, precisión de micro segundos en la Processlist, cache de índices
segmentada, etc.
41
CAPITULO III
MARCO APLICATIVO
3.1 INTRODUCCIÓN
En este capítulo se desarrollara el “Sistema Web para el Control y Seguimiento de
Afiliados a los Entes Gestores”, para el Instituto Nacional de Seguros de Salud (INASES)
siguiendo la metodología de desarrollo ágil SCRUM complementada con la metodología de
modelado web UWE, para poder obtener la representación física y conceptual del sistema
web.
En la siguiente figura se puede apreciar el modelo de proceso de desarrollo que se utilizó en

el presente proyecto, en esta figura se modela la combinación de la metodología SCRUM y
la metodología UWE, además de pasos extras que son muy importantes para el proyecto.
Figura 3.1: Modelo del proceso de desarrollo del proyecto

Fuente: [elaboración propia]
42
3.2 PRE JUEGO
3.2.1 DESCRIPCION DE USUARIOS

A continuación se detallas a los usuarios involucrados en este sistema:
USUARIO ABREV. DESCRIPCION
SuperAdministrador SA Es el responsable del área de informática de la institución.
Administrador A Personal del área de informática de la institución.
Operador O Son empleados de las empresas.
Persona P Cualquier persona residente en Bolivia.

Tabla 3.1: Descripción de Usuarios
Fuente: [Elaboración Propia]
3.2.2 PRODUCT BACKLOG

Para poder empezar a realizar las iteraciones primero necesitamos definir nuestra Lista de
requisitos priorizada (Product Backlog), para esto fue necesario realizar reuniones entre el
cliente (Product Owner), el líder de equipo (Scrum master) y el equipo de desarrollo
(Team). En este caso la función de cliente lo cumplió el Ing. Julio Prieto Peñaranda
responsable del área de Informática como representante del instituto nacional de seguros de
salud, el líder de equipo y a la vez equipo de desarrollo fue quien les escribe.
Para poder obtener el Product Backlog se entrevistó al cliente, preguntándole el proceso

actual que se tiene para obtener el certificado de no afiliación a los entes gestores y para
qué es necesario, y este de manera verbal indico que es un certificado que sirve a personas
que quieren afiliarse como nuevos beneficiarios y a los beneficiarios (personas afiliadas)
que necesitan re afiliarse para poder aportar a su ente gestor y recibir las prestaciones que
este brinda.
Se le pregunto también el proceso de reafiliación que sigue un beneficiario, y este de

manera verbal respondió: un beneficiario obtiene su certificado de no afiliación yendo
personalmente a los distintos entes gestores y haciendo sellar su formulario respectivo, en
este proceso actual el ir personalmente a los distintos entes gestores puede llevar mucho o
poco tiempo
43
dependiendo cuanto esfuerzo ponga la persona que lo requiere, ya que los entes gestores se
encuentran alejadas unas de otras, es por eso que se quiere sistematizar este proceso para
beneficiar a los bolivianos.
Una vez que un beneficiario obtenga su certificado, este lo entrega a su empleador para que
lo adjunte a una planilla, planilla en el que el empleador tiene la lista de sus empleados para
entregar a su ente gestor el cual realiza el proceso de re afiliación de los mencionados en la
planilla.
Viendo los detalles que el cliente proporciono se hizo un análisis de como recolectar la
información de los beneficiarios, y en otra reunión se construyó junto al cliente la siguiente
lista de requisitos:
LISTA DE REQUISITOS PRIORIZADA
ID Nombre Modulo Prioridad Tiempo de Como probarlo

desarrollo
1 Diseño de la Base de Demasiado 5 días Ver en el servidor la
datos y Arquitectura Alta implementación de la base de
del sistema datos y la lógica de
2 Autentificación de Muy Alta 6 días Ver el sistema web, y

Usuarios autenticarse con los datos de
Modulo prueba, se tiene éxito si este nos
Seguridad direcciona al menú principal.
4 Mostrar Acciones de Muy Alta 4 días Ver la lista de acciones que nos
Usuarios muestra el sistema
3 Crear/Actualizar Alta 8 días Usar el registro de nuevo

empleador empleador y actualización de
Modulo
datos de un empleador, se tiene
Registro
éxito cuando hacer cambios en
la base de datos.
44
6 Crear/Actualizar Alta 6 días Usar el formulario beneficiario
Beneficiarios para añadir o editar
beneficiarios, verificar cambios
en la base de datos.
7 Generar/Actualizar Media 10 días Usar el sistema para generar o

Planillas actualizar planillas, verificar los
terminados viendo su reporte
para imprimir.
8 Generar Reportes de Modulo Media 6 días Ir al listado de planillas verificar

las planillas Planillas apretando el botón que le
corresponde a cada planilla
finalizada, ver que salga una
nueva pestaña en el navegador
con el PDF para imprimir.
5 Administrar Baja 10 días Usar la administración de

Privilegios de menús y asignaciones de grupos
Usuarios a los usuarios verificando los
cambios en la base de datos,
9 Administrar Baja 8 dias Al generar una planilla un

Modulo
solicitudes de cambio empleador debe poder solicitar
Control
de datos de el cambio de datos de un
beneficiarios. beneficiario, y en el sistema un
administrador podrá atender las
solicitudes enviadas por los
empleadores.
10 Generar Certificado Muy Baja 6 dias Introduciendo el número de

de no afiliación a los documento (CI, pasaporte) de
entes gestores Modulo una persona podrá generar el
Consulta certificado en PDF para poder
imprimirlo.
45
11 Generar Certificado Muy Baja 4 dias Introduciendo el número de
de afiliación a un ente documento (CI, pasaporte) de
gestor una persona podrá generar el
certificado en PDF para poder
imprimirlo.
Tabla 3.2: Product Backlog
Fuente: [Elaboración propia]
3.2.3 REQUERIMIENTOS DE HARDWARE Y SOFTWARE

Para poder desarrollar el proyecto e implementarlo también necesitamos hardware y
software, en la siguiente tabla se mencionan los requerimientos mínimos para el buen
desarrollo e implementación del sistema web.
PC de escritorio o Laptop, con las siguientes características:
 Memoria RAM 1gb o Superior
 Espacio disponible en disco duro 10gb o superior

Requerimiento de Hardware
 Procesador Pentium 4 o superior
 Pantalla, teclado, mouse, impresora
Servidores basados en Linux
IDE NetBeans 8.0.1 para la codificación del sistema en el lenguaje PHP.
MagicDraw para crear modelos UWE
Requerimiento de Software Microsoft Word para la documentación
Apache para montar servidor HTTP.
Navicat 11.1.11 para la gestión de la base de datos MariaDB

Tabla 3.3: Requerimientos de Hardware y Software el desarrollo del
proyecto
3.3 JUEGO
De acuerdo el modelo que se propuso con la metodología SCRUM y UWE en la
introducción de este capítulo, en esta fase se desarrollaran los sprints seleccionando
requisitos del product backlog según su prioridad, posteriormente hacer la planificación, el
desarrollo y las pruebas de cada sprint.
46
Para la planificación solo se usara el sprint backlog el cual es una herramienta de SCRUM,
luego para la parte de desarrollo se hará uso de los diagramas que proporciona la
metodología UWE y codificar si es necesario para obtener incrementos, y al finalizar el
sprint se harán las pruebas unitarias del mismo.
3.3.1 SPRINT 1
3.3.1.1 PLANIFICACIÓN
En este sprint se escogió del product backlog el requerimiento con prioridad demasiado alta
el cual es “Diseño de la Base de datos y Arquitectura del sistema”.
Para el diseño de la base de datos se realizara el Modelo Relacional de la base de datos con
el que trabajara el sistema web.
Una vez concluido el diseño de la base de datos se procederá a diseñar la arquitectura con
la cual funcionara el sistema web.
Inicio Fin Duración
REQUISITO TAREA 20/07/2015 24/07/2015 5 días
Desde Hasta ESTADO
Diseño del Modelo

Diseño de la Base
Relacional de la base de 20/07/2015 22/07/2015 Completado
de datos y
datos e implementación
Arquitectura del
Diseño Arquitectura del
sistema 23/07/2015 24/07/2015 Completado
sistema
Tabla 3.4: Sprint Backlog 1
3.3.1.2 DESARROLLO
En este sprint se realizó dos tareas como se planifico en el sprint backlog 1, los cuales son
diseñar el modelo relacional de la base de datos e implementarlo, y diseñar la arquitectura
de software en el cual se pueda implementar el sistema web.
47
a) Se diseñó el Modelo Relacional de la base de datos pensando en cumplir todos los
requisitos en este paso es muy importante mencionar que se hizo uso de la teoría de
desnormalización, con la cual intencionalmente se duplico columnas en varias tablas,
esto con la intención de que posteriormente beneficie en la velocidad de respuesta de las
consultas que se haga a la base de datos.
Luego de diseñar el modelo se creó la base de datos en el sistema de gestión de base de
datos MariaDB.
Figura 3.2: Modelo Relacional de la Base de Datos

48
Después de diseñar el modelo relacional se realizó su diccionario de datos correspondiente,
el cual contiene el tipo y una breve descripción de los atributos de cada tabla que pertenece
al modelo relacional, el cual se puede visualizar en la siguiente tabla:
Diccionario de datos del modelo relacional
usuarios
atributo tipo descripción
id_usuario int numero único
nit varchar(50) nit de la empresa del empleador
usuario varchar(50) registro único de usuario
pass varchar(50) contraseña del usuario
nombre varchar(50) nombre del usuario
email varchar(50) correo del empleador
nom_empresa varchar(255) nombre del empleador
nom_corto varchar(20) sigla del nombre del empleador
cargo varchar(50) cargo que ocupa el usuario en su empleador
habilitado smallint especifica si el usuario puede ingresar al sistema, 1 puede 0 no

puede
session_activa int 1 si el usuario está usando el sistema 0 lo contrario
app varchar(50) nombre del sub sistema en el que se encuentra operando el

usuario
action_app varchar(255) ultima acción que realizo el usuario
ip_acc varchar(50) ip con el que el usuario se conecta al sistema.
fe_ult_acceso timestamp fecha y hora del último acceso del usuario.
fe_creacion timestamp fecha y hora en la que se creó el usuario
fe_habilitacion timestamp fecha y hora en la que se habilito el usuario
certificado varchar(255) certificado que se le da al usuario cada vez que se loguea, para
controlar que ingrese solo desde un navegador,
ssid varchar(255) cookie del servidor al usuario
49
id_serv int id del servidor al que se conecta el usuario
id_emp int id del empleador al que pertenece el usuario
id_entges int id del ente gestor al que pertenece el empleador
log
id int numero único
fecha timestamp fecha y hora en la que se crea un log
app varchar(50) sub sistema que se hizo uso
acción varchar(255) acción que realizo el usuario
descrip varchar(255) detalles de la acción que realizo el usuario
usr varchar(50) usuario que realizo la acción
ip varchar(50) ip con el que el usuario se conecta al sistema.
servidores
tipo varchar(10) tipo de servidor: primario – en el que los usuarios se loguean y

servicio – una vez logueado pasa a usar uno de estos servidores
dominio varchar(255) url/ip del servidor
cantidad int cantidad de usuarios que se encuentran conectados a dicho

servidor.
estado int puede tener el valor 1 cuando el servidor está funcionando

correctamente o 0 para cuando ocurra un error o se le quiera
hacer soporte.
entegestor
código varchar(50) código corto
descripción varchar(255) nombre completo del ente gestor
estado int 1 si el ente gestor está activo o 0 en caso contrario
50
aclusrgroup
idusuario int id del usuario
idgroup int id del grupo
estado int puede tener el valor 1 cuando la relación está activa o 0 inactivo
aclgroup
idapp int id de la aplicación
descrip varchar(100) descripción del grupo
estado int puede tener el valor 1 cuando está activa o 0 inactivo
aclnaccesos
idgroup int id del grupo al que pertenece
descrip varchar(100) descripción del acceso
dir varchar(255) dirección url a la que apunta el acceso
icon varchar(50) nombre del icono que tendrá el acceso
aclapp
identificador varchar(50) identificador de la aplicación
icon varchar(50) nombre del icono que tendrá la aplicación
dirint varchar(255) dirección interna q se maneja con los servidores
descrip varchar(50) descripción de la aplicación
nivel int lugar de despliegue por niveles
51
empleador
nit varchar(50) nit de la empresa
código varchar(50) código único que consta de: emp-<idemp>-<fechacreacion>
descripción varchar(255) nombre de la empresa
dirección varchar(255) dirección de la empresa
correo varchar(50) email de la empresa
numcontacto varchar(50) numero de celular o teléfono de la empresa
razonsocial varchar(50) tipo de empresa “publica” o “privada”
fecha date fecha de inserción del empleador
identegestor int id del ente gestor de la empresa
planilla
código varchar(50) generamos único de planilla p-<idempleador>-<mes>-<año>
idempleador int id del empleador que genera la planilla
gestión int año al que pertenece la planilla
periodo int mes al que pertenece la planilla
observaciones varchar(255) observaciones que tiene la planilla
fechagen timestamp fecha y hora en que se genera la planilla.
estado int bandera eliminado o no
estadoacep varchar(50) estado en el que se encuentra la planilla “aceptado” o “en

proceso”
estadotabla varchar(50) especifica en que tabla esta la lista de beneficiarios de la

planilla, puede ser temporal, oficial o historial.
52
Fechaaceptado timestamp fecha y hora en la que se acepta la planilla
planillabeneficiario
idplanilla int id planilla al que pertenece
codigoplanilla varchar(70) código único que consta del empleador de: emp-<idemp>-
<fechacreacion>
idempledor int id del empleador
codigoempleador varchar(50) código único del empleado que consta de: emp-<idemp>-
<fechacreacion>
descripempleador varchar(255) nombre del empleador
periodoplanilla int mes al que pertenece la planilla
gestionplanilla int año al que pertenece la planilla
idbeneficiario int id del beneficiario
ci varchar(50) numero de documento del beneficiario
extensión varchar(50) extensión de documento del beneficiario
codigoben varchar(70) código único del beneficiario que consta de:

1ºletranombre+1ºletraappaterno+1ºletraapmaterno-
(dia+mes+año+(id)dadovuelta)transformado base 64
nombrebeneficiario varchar(70) nombre del beneficiario
appaterno varchar(70) ap. paterno del beneficiario
apmaterno varchar(70) ap. materno del beneficiario
apcasada varchar(70) ap. casada del beneficiario si es mujer
fechanac date fecha de nacimiento del beneficiario
sexo varchar(50) sexo del beneficiario
tipobeneficiario varchar(50) tipo de beneficiario, independiente o dependiente
iddependientebeneficiario int null si es independiente o el id del que depende el beneficiario
fecha timestamp fecha creación del beneficiario
53
fechasesantia timestamp fecha de sesantia, fecha límite para que el beneficiario pueda
cotizar a su ente gestor
bandera varchar(255) en que tabla está el registro, temporal o oficial o historial.
obserbacion varchar(255) observación que el beneficiario puede tener
codanteben varchar(50) código anterior del beneficiario
regional varchar(255) regional a la que pertenece el beneficiario
identegestor int id del ente gestor al que pertenece el beneficiario
codigoentegestor varchar(50) código del ente gestor al que pertenece el beneficiario
descripcionentegestor varchar(255) descripción del ente gestor al que pertenece el beneficiario
beneficiario
código varchar(70) código único del beneficiario que consta de:

1ºletranombre+1ºletraappaterno+1ºletraapmaterno-
(dia+mes+año+(id)dadovuelta)transformado base 64
ci varchar(50) numero de documento del beneficiario
extensión varchar(50) extensión de documento del beneficiario
codant varchar(50) código anterior del beneficiario
nombre varchar(70) nombre del beneficiario
appaterno varchar(70) ap. paterno del beneficiario
apmaterno varchar(70) ap. materno del beneficiario
apcasada varchar(70) ap. casada del beneficiario si es mujer
fechanac date fecha de nacimiento del beneficiario
nivelbeneficiario varchar(50) tipo de beneficiario, independiente o dependiente
sexo varchar(50) sexo del beneficiario
iddependientebeneficiario int id del ente gestor al que pertenece el beneficiario

Tabla 3.5: Diccionario de datos de la base de datos del sistema web
b) En la arquitectura de software a se tomó muy en cuenta que el sistema iba a funcionar
para muchos usuarios por lo que se pensó directamente en diseñar una arquitectura de 3
54
capas con la característica de que en la capa de negocios se haga uso de más servidores
para poder balancear la carga que estos tendrán al atender las peticiones de los usuarios,
además que en la capa de datos se haga uso de la base datos espejo. En la siguiente
figura se muestra el diseño de la arquitectura de software en la que se implementará el
sistema web.
Figura 3.3: Diseño de la arquitectura de software.

3.3.1.3 PRUEBAS
Se hizo las pruebas unitarias al servidor de base de datos donde se implementó la base de
datos.
NRO DESCRIPCION DEL CASO DE PRUEBAS RESULTADO
1 Se puede hacer consultas a la base de datos Cumple
2 La base de datos espejo funciona correctamente Cumple
3 Se puede ingresar al servidor primario Cumple

Tabla 3.6: Pruebas unitarias del sprint 1
55
3.3.2 SPRINT 2
En este sprint se escogió del product backlog los requisitos con prioridad muy alta los
cuales son “Autentificación de Usuarios” y “Mostrar Acciones de Usuarios” que pertenecen
al módulo de seguridad, luego se realizó el Sprint Backlog correspondiente, el cual se lo
muestra en la siguiente tabla:
Desde Hasta ESTADO
Diseño diagramas UWE 27/07/2015 27/07/2015 Completado

Autentificación de
Codificación 29/07/2015 03/08/2015 Completado
Usuarios
Pruebas 04/08/2015 04/08/2015 Completado

Mostrar acciones de
usuarios
3.3.2.2 DESARROLLO
Después de diseñar el Sprint Backlog 2, inmediatamente se empezó a diseñar los diagramas
que UWE nos proporciona de cada requisito, para luego pasar a la codificación de los
mismos.
En este sprint y los siguientes se usó las tecnologías web que se especifican en el capítulo 2,
como ser el framework Bootstrap para crear las ventanas que podrán visualizar los clientes
con un navegador, también el framework Yii2 que está basado en PHP y sirve para
programar la lógica del sistema, MariaDB como sistema para gestionar la base de datos del
sistema que se conecta únicamente con la capa lógica y los servidores propuestos en el
diseño de la arquitectura de software.
56
a) Modelo de Requerimientos
Se diseñó el diagrama de casos de uso para los requisitos “Autentificación de Usuarios” y
“Mostrar Acciones de Usuarios”, el cual se lo visualiza en la siguiente figura:
Figura 3.4: Diagrama de Casos de Uso de los requisitos Autentificación

de Usuarios y Mostrar acciones de usuarios.
b) Modelo de Contenidos
Se diseñó el diagrama de contenido para los requisitos “Autentificación de Usuarios” y
Figura 3.5: Diagrama de Contenido de los requisitos Autentificación de

Usuarios y Mostrar acciones de usuarios.
c) Modelo de Navegación
Se diseñó el diagrama de navegación para los requisitos “Autentificación de Usuarios” y
57
Figura 3.6: Diagrama de Navegación de los requisitos Autentificación de
Usuarios y Mostrar acciones de usuarios.
d) Modelos de Presentación
Se diseñó el diagrama de presentación para los requisitos “Autentificación de Usuarios” y
“Mostrar Acciones de Usuarios”. En este modelo solo se usaran los iconos de los
estereotipos para una mejor visualización de los diagramas. En las siguientes figuras se
muestra el diagrama de presentación de las pantallas que nos indica el diagrama de
navegación, los cuales son SISAF ingreso, SISAF y listar logs.
Figura 3.7: Modelo de Presentación de la autentificación de Usuarios.

Fuente [Elaboración propia]
58
Figura 3.8: Diagrama de Presentación del Sistema Web.
Figura 3.9: Modelo de Presentación de Mostrar acciones de usuarios.

59
3.3.2.3 PRUEBAS
Después de codificar, se hizo las pruebas unitarias al módulo de seguridad desarrollado.
1 El formulario de la autentificación tiene validadores Cumple
2 Después de llenar datos correctos el formulario nos direcciona al menú Cumple

principal del sistema.
3 La Lista de Logs (acciones) de los usuarios nos muestra todos los datos Cumple
requeridos en el diagrama de presentación.
3.3.3 SPRINT 3
En este sprint se escogió del product backlog los requisitos con prioridad alta los cuales son
“Crear/Actualizar empleador” y “Crear/Actualizar Beneficiarios” que pertenecen al módulo
de registro, luego se realizó el Sprint Backlog correspondiente.
Desde Hasta ESTADO
Crear/Actualizar Diseño diagramas UWE 10/08/2015 10/08/2015 Completado

empleador Codificación 12/08/2015 19/08/2015 Completado
Crear/Actualizar Diseño diagramas UWE 11/08/2015 11/08/2015 Completado

Beneficiarios Codificación 21/08/2015 26/08/2015 Completado

3.3.3.2 DESARROLLO
Después de diseñar el Sprint Backlog 3, inmediatamente se empezó a diseñar los modelos
UWE de cada requisito para luego pasar a la fase de codificación de los mismos.
60
Se diseñó el diagrama de casos de uso para los requisitos “Crear/Actualizar empleador” y
“Crear/Actualizar Beneficiarios”, el cual se lo visualiza en la siguiente figura:
Figura 3.10: Diagrama de Casos de Uso de los requisitos Crear/Actualizar

Empleador y Crear/Actualizar Beneficiarios
Se diseñó el diagrama de contenidos para los requisitos “Crear/Actualizar empleador” y
“Crear/Actualizar Beneficiarios”, el cual se lo visualiza en la siguiente figura:
Figura 3.11: Diagrama de Contenidos de los requisitos Crear/Actualizar

Empleador y Crear/Actualizar Beneficiarios
61
a) Modelo de Navegación
Se diseñó el diagrama de navegación para los requisitos “Crear/Actualizar empleador” y
“Crear/Actualizar Beneficiarios”. En este caso se hará por separado un diagrama de
navegación por requisito.
Figura 3.12: Diagrama de Navegación del requisito Crear/Actualizar

Empleadores
Figura 3.13: Diagrama de Navegación del requisito Crear/Actualizar

Beneficiarios
62
b) Modelos de Presentación
Se diseñó el diagrama de presentación para los requisitos “Crear/Actualizar empleador” y
“Crear/Actualizar Beneficiarios”. En este modelo solo se usaran los iconos de los
estereotipos para una mejor visualización de los diagramas.
En las siguientes figuras se muestra el diagrama de presentación de las pantallas que nos
indican los diagramas de navegación.
Para el requisito Crear/Actualizar Empleadores se diseñó un diagrama de presentación el

cual sirve para ambos casos crear y actualizar los datos de un empleador.
Figura 3.14: Diagrama de Presentación del requisito Crear/Actualizar

Empleadores.
Para el requisito Crear/Actualizar Beneficiarios se diseñó un diagrama de presentación el
cual sirve para ambos casos crear y actualizar los datos de un beneficiario. Y también un
diagrama de presentación que muestra una lista de beneficiarios.
63
Figura 3.15: Modelo de Presentación de Crear/Actualiza Beneficiarios.
Figura 3.16: Modelo de Presentación de Listar Beneficiarios.

64
3.3.3.3 PRUEBAS
Después de codificar, se hizo las pruebas unitarias al módulo de registro desarrollado.
1 El formulario de empleador tiene validadores Cumple
2 Después de llenar datos correctos el formulario de empleador crea un nuevo Cumple

empleador
2 Después de llenar datos correctos el formulario de empleador edita un Cumple

empleador
4 El formulario de beneficiario tiene validadores Cumple
5 Después de llenar datos correctos el formulario de beneficiario crea un nuevo Cumple

beneficiario
6 Si un beneficiario ya existe el formulario de beneficiario se llena con los datos Cumple

existentes.
7 Después de llenar datos correctos el formulario de beneficiario edita un Cumple

beneficiario
8 La lista de beneficiarios muestra los datos de beneficiarios. Tiene paginación, Cumple

y búsqueda de datos
3.3.4 SPRINT 4
En este sprint se escogió del product backlog los requisitos con prioridad media los cuales
son “Generar/Actualizar Planillas” y “Generar Reportes de las planillas” que pertenecen al
módulo de planillas, luego se realizó el Sprint Backlog correspondiente.

Desde Hasta ESTADO
Generar/Actualizar Diseño diagramas UWE 28/08/2015 28/08/2015 Completado
Planillas Codificación 01/09/2015 10/09/2015 Completado
65
Generar Reportes Diseño diagramas UWE 31/08/2015 31/08/2015 Completado
de las planillas Codificación 14/09/2015 17/09/2015 Completado
Tabla 3.11 Sprint Backlog 4
3.3.4.2 DESARROLLO
Se diseñó el diagrama de casos de uso para los requisitos “Generar/Actualizar Planillas” y
“Generar Reportes de las planillas”, el cual se lo visualiza en la siguiente figura:
Figura 3.17: Diagrama de Casos de Uso de los requisitos

Generar/Actualizar Planillas y Generar Reportes de las
planillas Fuente: [Elaboración propia]
Se diseñó el diagrama de contenidos para los requisitos “Generar/Actualizar Planillas” y
66
Figura 3.18: Diagrama de Contenidos de los requisitos Generar/Actualizar
Planillas y Generar Reportes de las planillas
Se diseñó el diagrama de navegación para los requisitos “Generar/Actualizar Planillas” y
Figura 3.19: Modelo de Navegación de Crear/Actualizar Planillas

67
Se diseñó el diagrama de presentación para los requisitos “Generar/Actualizar Planillas” y
“Generar Reportes de las planillas”. En este modelo solo se usaran los iconos de los
estereotipos para una mejor visualización de los diagramas.
indica el diagrama de navegación. Los cuales son generar planilla, lista de planillas, planilla
beneficiarios que se subdivide en formulario beneficiario y lista de beneficiarios, y
finalmente el reporte planilla PDF.
La siguiente figura nos muestra el diagrama de presentación de generar planilla que

pertenece al requisito “Generar/Actualizar Planillas”.
Figura 3.20: Diagrama de Presentación de Generar Planilla

La siguiente figura nos muestra el diagrama de presentación de listar planillas que
68
Figura 3.21: Diagrama de Presentación de Lista de Planillas.
La siguiente figura nos muestra el diagrama de presentación de planilla beneficiarios que
Figura 3.22: Diagrama de Presentación de Crear/Añade Beneficiarios.

69
La siguiente figura nos muestra el diagrama de presentación de listar beneficiarios que
Figura 3.23: Diagrama de Presentación de Listar Beneficiarios.

La siguiente figura nos muestra el diagrama de presentación de listar beneficiarios que
pertenece al requisito “Generar Reportes de las planillas”.
Figura 3.24: Diagrama de Presentación de reporte planilla PDF

70
3.3.4.3 PRUEBAS
Después de codificar, se hizo las pruebas unitarias al módulo de planillas desarrollado.
1 Generar planilla crea nueva planilla con los datos introducidos. Cumple
2 Generar planilla puede generar planillas con datos de planillas anteriores. Cumple
2 La lista de planillas muestra los datos de planillas terminadas y en proceso, Cumple
4 La lista de planillas tiene paginación, ordenamiento de datos y búsqueda de Cumple

datos.
5 Después de llenar datos correctos el formulario de beneficiario crea un nuevo Cumple

beneficiario.
6 Después de llenar datos correctos el formulario de beneficiario añade un Cumple

beneficiario a la lista de beneficiarios.
7 El formulario de beneficiario puede llenarse automáticamente con los datos de Cumple

un beneficiario que ya existe en la base de datos.
8 La lista de beneficiarios muestra los datos de beneficiarios. Tiene paginación Cumple

y búsqueda de datos
3.3.5 SPRINT 5
En este sprint se escogió del product backlog los requisitos con prioridad baja los cuales
son “Administrar Privilegios de Usuarios” y “Administrar solicitudes de cambio de datos
de beneficiarios” que pertenecen al módulo de control, luego se realizó el Sprint Backlog
correspondiente.

Desde Hasta ESTADO
71
Administrar
Privilegios de
Usuarios
Administrar Diseño diagramas UWE 22/09/2015 22/09/2015 Completado

solicitudes de Codificación 06/10/2015 13/10/2015 Completado
cambio de datos de
beneficiarios
3.3.5.2 DESARROLLO
Se diseñó el diagrama de casos de uso para los requisitos “Administrar Privilegios de
Usuarios” y “Administrar solicitudes de cambio de datos de beneficiarios de parte de los
empleadores”, el cual se lo visualiza en la siguiente figura:
Figura 3.25: Diagrama de Casos de Uso de los requisitos Administrar

Privilegios de Usuarios y Administrar solicitudes de cambio de datos de
beneficiarios
72
Se diseñó el diagrama de contenidos para los requisitos “Administrar Privilegios de
Usuarios” y “Administrar solicitudes de cambio de datos de beneficiarios”, el cual se lo
visualiza en la siguiente figura:
Figura 3.26: Diagrama de Contenidos de los requisitos Administrar

Privilegios de Usuarios y Administrar solicitudes de cambio de datos de
beneficiarios
Se diseñó el diagrama de navegación para los requisitos “Administrar Privilegios de
Usuarios” y “Administrar solicitudes de cambio de datos de beneficiarios de parte de los
empleadores”, en este caso se hará dos modelos de navegación ya que los requisitos son
muy complejos. Para el requisito Administrar privilegios de usuarios se harán dos
diagramas de navegación, los cuales son administrar grupos y asignar grupos.
73
La siguiente figura nos muestra el diagrama de navegación de administrar menus.
Figura 3.27: Diagrama de Navegación de administrar grupos

La siguiente figura nos muestra el diagrama de navegación de asignar grupos.
Figura 3.28: Diagrama de Navegación de Asignar Grupos

74
La siguiente figura nos muestra el diagrama de navegación de administrar solicitudes de
cambio de datos de beneficiarios.
Figura 3.29: Diagrama de Navegación de Administrar solicitudes de

cambio de datos de beneficiarios
Se diseñó el diagrama de navegación para los requisitos “Administrar Privilegios de
Usuarios” y “Administrar solicitudes de cambio de datos de beneficiarios”. En este modelo
solo se usaran los iconos de los estereotipos para una mejor esquematización.
indica el diagrama de navegación. Los cuales son administrar menús que se compone de 3
formularios, asignar grupos que se divide en lista de usuarios y grupos de usuario.
La siguiente figura nos muestra el diagrama de presentación administrar menús y sus

respectivos formularios.
75
Figura 3.30: Diagrama de Presentación de la Administración de Usuarios.
Figura 3.31: Diagrama de Presentación del Formulario App.

Figura 3.32: Diagrama de Presentación del Formulario Grupo.

76
Figura 3.33: Diagrama de Presentación del Formulario Acceso.
La siguiente figura nos muestra el diagrama de presentación lista de usuarios.
Figura 3.34: Diagrama de Presentación de la Lista de Usuarios que es

parte de Asignar Grupos.
77
La siguiente figura nos muestra el diagrama de presentación asignar grupos.
Figura 3.35: Diagrama de Presentación de los Datos y Grupos de un

Usuario que es parte de Asignar Grupos.
3.3.5.3 PRUEBAS
1 En administrar menús se puede crear/editar apps de grupo. Cumple
2 En administrar menús se puede crear/editar accesos de grupo. Cumple
2 En administrar menús se puede crear/editar datos del grupo. Cumple
4 La lista de usuarios muestra los datos de beneficiarios. Tiene paginación, Cumple

ordenamiento y búsqueda de datos
5 Se puede asignar grupos a un usuario Cumple
6 Se puede cambiar el estado de los grupos de un usuario Cumple

78
3.3.6 SPRINT 6
En este sprint se escogió del product backlog los requisitos con prioridad baja los cuales
son “Generar Certificado de no afiliación a los entes gestores” y “Generar Certificado de
afiliación a un ente gestor” que pertenecen al módulo de control, luego se realizó el Sprint
Backlog correspondiente.
Desde Hasta ESTADO
Generar Certificado Diseño diagramas UWE 15/10/2015 15/10/2015 Completado

de no afiliación a Codificación 19/10/2015 22/10/2015 Completado
los entes gestores
Generar Certificado Diseño diagramas UWE 16/10/2015 16/10/2015 Completado

de afiliación a un Codificación 26/10/2015 27/10/2015 Completado
ente gestor
3.3.6.2 DESARROLLO
Se diseñó el diagrama de casos de uso para los requisitos “Generar Certificado de no
afiliación a los entes gestores” y “Generar Certificado de afiliación a un ente gestor”, el
cual se lo visualiza en la siguiente figura:
79
Figura 3.36: Diagrama de Casos de Uso de los requisitos Generar
Certificado de no afiliación a los entes gestores y Generar Certificado de
afiliación a un ente gestor
Se diseñó el diagrama de contenidos para los requisitos “Generar Certificado de no
Figura 3.37: Diagrama de Contenidos de los requisitos Generar

Certificado de no afiliación a los entes gestores y Generar Certificado
de afiliación a un ente gestor
80
Se diseñó el diagrama de navegación para los requisitos “Generar Certificado de no
Figura 3.38: Diagrama de Navegación de los requisitos Generar

Certificado de no afiliación a los entes gestores y Generar Certificado de
afiliación a un ente gestor
Se diseñó los diagramas de presentación para los requisitos “Generar Certificado de no
afiliación a los entes gestores” y “Generar Certificado de afiliación a un ente gestor”.
Figura 3.39: Diagrama de Presentación de Formulario Certificado

81
La siguiente figura nos muestra el diagrama de presentación del certificado único de
afiliación.
Figura 3.40: Diagrama de Presentación de Certificado Único de Afiliación

3.3.6.3 PRUEBAS
1 Se genera el Certificado de no afiliación a los entes gestores. Cumple
2 Se genera el Certificado de afiliación a un ente gestor. Cumple

3.4 POST JUEGO

De acuerdo al modelo de proceso que se sigue en el capítulo actual se realizó las pruebas de
integridad y pruebas de sistema.
82
3.4.1 PRUEBAS DE INTEGRACIÓN
Las pruebas de integración se refieren a ver si los módulos funcionan correctamente en
conjunto una vez que estos han sido probados unitariamente, con el fin de comprobar que
interactúan correctamente a través de sus interfaces. Estas pruebas fueron realizadas por el
equipo de desarrollo que realizo pruebas de integración sobre el sistema, además verifico el
correcto funcionamiento del sistema en la arquitectura de software que se diseñó y que la
base de datos se conecte a todo el sistema.
La siguiente tabla muestra las pruebas de integración que se hicieron:
1 Después de que un usuario se autentifica correctamente le direcciona al menú Cumple

principal donde podrá interactuar con los permisos que se le concede
2 El sistema lista las acciones que hicieron los usuarios en cualquier módulo. Cumple
3 Los cambios que se hacen en beneficiarios o empleadores con el modulo Cumple

registro afectan a los demás módulos.
4 Los cambios que se hagan administrando los grupos de usuarios del módulo Cumple
control, afectan al menú principal de cada usuario.
5 Al generar o actualizar planillas se hace uso de los datos con los que trabaja el Cumple
modulo registro.
6 Las solicitudes de cambio de datos de beneficiarios que se hacen con el Cumple

modulo
control, se integra con el modulo registro.
7 Para generar los certificados de afiliación del módulo consulta se hace uso de Cumple
los datos que se generan con el modulo planillas.
8 Todos los módulos están conectados con la base de datos. Cumple
9 El sistema funciona correctamente en la arquitectura de software propuesta. Cumple

Tabla 3.17: Pruebas de integración del sistema web
3.4.2 PRUEBAS DE SISTEMA

Luego de hacer las pruebas de integración que fueron realizadas por los desarrolladores, se
procedió a hacer las pruebas del sistema para comprobar que este cumpla con las
expectativas
83
del cliente. Para lo cual el Scrum Master presento al cliente el sistema web completo, luego
el cliente realizo pruebas del buen funcionamiento de todas las interfaces del sistema y
quedo satisfecho con el proyecto.
A continuación se presentan los diseños de interfaz finales del sistema.
a) Menú Principal
Pantalla principal del sistema en la que funcionan todos los módulos, se puede acceder a
esta pantalla después de una correcta autentificación del usuario. Esta pantalla cuenta con
menús desplegables que se generaran de acuerdo a los accesos que se les concede a los
usuarios. Todos los enlaces se cargaran en el panel principal el cual cambiara
dinámicamente según lo requerido al usuario.
Figura 3.41: Pantalla principal del sistema SisAf

b) Modulo Seguridad – Autentificación
Pantalla de ingreso al sistema con el cual los usuarios deben autentificarse para poder
acceder al menú principal del sistema. Esta pantalla cuenta con validadores de campos y
código captcha para una mayor seguridad, además de que tiene enlaces que direccionan al
formulario para crear usuarios y generar certificados de afiliación.
84
Figura 3.42: Pantalla de autentificación
c) Modulo Seguridad - Lista de Logs (acciones de usuarios)
Pantalla que lista las acciones de los usuarios, la cual se puede acceder desde el menú
principal. Esta pantalla cuenta con un buscador que funciona con todos los datos de la tabla,
paginador y selector para mostrar una cantidad de filas, además muestra la cantidad de
datos que se tiene.
Figura 3.43: Pantalla de la Lista de Log

85
d) Modulo Registro - Formulario de Usuario (empleador)
Pantalla del formulario de empleador que sirve para crear y actualizar usuarios. La figura
xx muestra el formulario para crear un nuevo usuario, tiene validadores y código captcha
que cuentan como parte de la seguridad. El formulario para actualizar un usuario es el
mismo pero con menos campos.
Figura 3.44: Pantalla del Formulario de Usuario

e) Modulo Registro - Formulario de Beneficiario

Pantalla del formulario de beneficiario que sirve para crear y actualizar beneficiarios, la
cual se puede acceder desde el menú principal. Esta pantalla tiene validadores para todos
los campos, también se llena automáticamente con los datos de un beneficiario (si es que
este existe en la base de datos) cuando se valida el código anterior o el documento.
86
Figura 3.45: Pantalla del Formulario de Beneficiario
f) Modulo Registro - Lista de Beneficiarios
Pantalla que lista los beneficiarios existentes en la base de datos, la cual se puede acceder
desde el menú principal. Esta pantalla cuenta con un buscador para cada una de las
columnas, paginador y siempre mostrara 10 filas, además muestra la cantidad de datos que
se tiene.
Figura 3.46: Pantalla del Formulario de Beneficiario

g) Modulo Planilla - Generar Planilla
Pantalla con la que se puede crear una nueva planilla, la cual se puede acceder desde el
menú principal. Esta pantalla además de un campo para gestión (año) en la que se generara
la planilla, cuenta con un selector para el periodo (mes) y también un selector para usar una
lista que fue generada anteriormente.
87
Figura 3.47: Pantalla de Generar una nueva Planilla
h) Modulo Planilla - Listar Planillas
Pantalla que lista las planillas generadas, la cual se puede acceder desde el menú principal.
Esta pantalla cuenta con un buscador para cada una de las columnas, su respectivo
paginador y siempre mostrara 10 filas, además para cada fila genera un enlace para o bien
actualizar la planilla no terminada o bien generar reporte de la planilla terminada.
Figura 3.48: Pantalla la Lista de Planillas

i) Modulo Planilla - Formulario de Beneficiario en Planillas
Pantalla del formulario de beneficiario en planillas que sirve para añadir y solicitar cambio
de datos de algún beneficiario, la cual se puede acceder desde generar o actualizar una
planilla. Esta pantalla tiene validadores para todos los campos, también se llena
automáticamente con los datos de un beneficiario (si es que este existe en la base de datos)
cuando se valida el código anterior o el documento. Y cuando se pula solicitar cambio de
datos el sistema hará que eso se cuente como una solicitud.
88
Figura 3.49: Pantalla del Formulario de Beneficiario en Planillas
j) Modulo Planilla - Lista de Beneficiarios en Planillas
Pantalla que lista los beneficiarios existentes en una planilla, la cual se puede acceder desde
generar o actualizar una planilla. Esta pantalla cuenta con un buscador para cada una de las
columnas, paginador y siempre mostrara 10 filas, además para cada fila cuenta con la
opción de editar datos de un beneficiario o eliminarlo de la planilla.
Figura 3.50: Pantalla la Lista de Beneficiarios en Planillas

89
k) Modulo Planilla - Reporte PDF de Planillas
Pantalla que lista los beneficiarios existentes en una planilla terminada, la cual se puede
acceder desde la lista de planillas. Esta pantalla es un PDF que puede ser imprimido o
guardado y cuenta con códigos QR y PDF417 los cuales guardan información para que se
pueda verificar su autenticidad al momento de usar el reporte.
Figura 3.51: Pantalla del Reporte PDF de Planillas

l) Modulo Control - Administrar Menús

Pantalla que se conforma de dos paneles, en el izquierdo se lista los accesos que pueden
tener los usuarios y que se va actualizando conforme se vayan creando o editando los
accesos que puede tener un usuario.
En el panel de lado derecho se muestra formularios en los que se puede crear o editar los
accesos, grupos y apps; estos formularios se visualizan de forma dinámica cuando se pulsen
los pequeños botones del panel izquierdo.
Se puede acceder a esta pantalla desde el menú principal y solo podrá ser manipulada por
los usuarios permitidos.
90
Figura 3.52: Pantalla de Administrar Menús
 Modulo Control - Formulario de Acceso

En la siguiente figura se muestra el formulario de acceso que es parte de la pantalla
administrar menús.
Figura 3.53: Pantalla de Formulario de Acceso

 Modulo Control - Formulario de Grupo

En la siguiente figura se muestra el formulario de grupo que es parte de la pantalla
administrar menús.
Figura 3.54: Pantalla de Formulario de Acceso

91
 Modulo Control - Formulario de App
En la siguiente figura se muestra el formulario de app que es parte de la pantalla
administrar menús.
Figura 3.55: Pantalla de Formulario de App

m) Modulo Control - Lista de Usuarios

Pantalla que lista los usuarios que existen en el sistema, la cual se puede acceder desde el
menú principal. Esta pantalla cuenta con un buscador que funciona con todos los datos de la
tabla, paginador y selector para mostrar una cantidad de filas, además muestra la cantidad
de datos que se tiene y un botón por cada fila para editar los grupos que tiene un usuario.
Esta pantalla tiene los datos básicos de un usuario para que sea fácil ubicarlos en la tabla.
Figura 3.56: Pantalla de la Lista de Usuarios

92
n) Modulo Control - Asignar Grupos a un usuario
Pantalla en la que se puede asignar grupos al usuario elegido en la pantalla de la lista de
usuarios. Esta pantalla cuenta con 2 paneles, en el izquierdo se visualizan los datos del
usuario que no se pueden editar y también la lista de grupos que este tiene, de los cuales se
puede editar su estado. En el panel derecho se tiene la lista de grupos y que se pueden
adicionar al usuario.
Figura 3.57: Pantalla de la Lista de Usuarios

o) Modulo Consulta - Formulario de Certificado

Pantalla del formulario de certificado que se puede acceder desde la pantalla de
autentificación. Este formulario tiene validadores de campos, y al pulsar generar se enviara
un correo electrónico al email introducido que contendrá un enlace para direccionar a la
pantalla del certificado.
El sistema internamente consultara si los datos introducidos son correctos, además que si
estos existen en la base de datos del instituto nacional de seguros de salud (INASES) o del
servicio general de identificación personal (SEGIP).
Si existe en el INASES se generara un certificado de afiliación a un ente gestor y si existe
en el SEGIP se generara un certificado de no afiliación.
93
Figura 3.58: Pantalla del formulario de Certificado
p) Modulo Consulta - Certificado

Pantalla en la cual se muestra el certificado único de afiliación que será proporcionado por
el instituto nacional de seguros de salud, este certificado o bien certificara que una persona
se encuentra afiliada a un ente gestor o bien no se encuentra afiliada a ningún ente gestor.
Una vez que se genere un certificado este tendrá un periodo de tiempo de 3 días para poder
ser descargado o imprimido, y 3 semanas para poder usarlo en trámites.
El certificado cuenta con código QR y código PDF417 que guardaran información para
verificar su autenticidad y su validez al momento de usarlo.
Esta pantalla solo podrá ser accedida desde el email que se manda con el formulario de
certificado, ya que contendrá información encriptada que solo el sistema puede descifrar.
94
Figura 3.59: Pantalla del Certificado Único de Afiliación
95
CAPITULO IV
CALIDAD Y SEGURDAD DEL SOFTWARE
4.1 NORMA ISO 9126

Es un estándar internacional para la evaluación de la calidad de productos de software el
cual fue publicado en 1992 con el nombre de “Information technology –Software product
evaluation: Quality characteristics and guidelines for their use”, en el cual se establecen las
características de calidad para productos de software.
El estándar ISO-9126 establece que cualquier componente de la calidad del software puede
ser descrito en términos de una o más de seis características básicas, las cuales son:
 Funcionalidad.- Es la capacidad del software de proveer las funciones para

satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones
específicas.
 Confiabilidad.- Es la capacidad del software para asegurar un nivel de

funcionamiento adecuado cuando es utilizando en condiciones específicas, por
cierto tiempo.
 Usabilidad.- Es la capacidad del software de ser entendido, aprendido, y usado de

forma fácil y atractiva.
 Mantenibilidad.- Es la cualidad que tiene el software para ser modificado.

Incluyendo correcciones o mejoras del software, a cambios en el entorno, y
especificaciones de requerimientos funcionales.
 Portabilidad.- La capacidad que tiene el software para ser trasladado de un entorno

a otro.
96
4.1.1 FUNCIONALIDAD
La funcionalidad es la capacidad del software de proveer las funciones para satisfacer las
necesidades explícitas e implícitas cuando es utilizado en condiciones específicas, este
atributo del sistema no puede medirse forma directa, por esa razón para el cálculo de la
funcionalidad utilizaremos la métrica de punto función, para esto se debe determinar cinco
características de dominios de información. Los valores de información se definen de la
siguiente forma.
 Número de entradas de usuario. Se cuenta cada entrada de usuario que

proporciona diferentes datos orientados a la aplicación. Las entradas se deberían
diferenciar de las peticiones, las cuales se cuentan de forma separada.
 Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario

información orientada a la aplicación. En este contexto la salida se refiere a
informes, pantallas, mensajes de error, etc.
 Número de peticiones de usuario. Una petición se define como una entrada

interactiva que produce la generación de alguna respuesta del software inmediata en
forma de salida interactiva. Se cuenta cada petición por separado.
 Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo
lógico de datos que puede ser una parte de una gran base de datos o un archivo
independiente).
 Número de interfaces externas. Se cuentan todas las interfaces legibles por la

máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para
transmitir información a otro sistema.
Para calcular los puntos función se usó la siguiente formula:
𝑃𝐹 = 𝐶𝑢𝑒𝑛𝑡𝑎 𝑇𝑜𝑡𝑎𝑙 ∗ (0.65 + 0.01 ∗ ∑ 𝐹𝑖 )
97
Donde:
PF: Medida de funcionalidad.
Cuenta Total: Es la suma de los siguientes datos: Nº de Entradas, Nº de Salidas, Nº de
Peticiones, Nº de Archivos y Nº de Interfaces externas.
0.65: Confiabilidad del proyecto, varia de 1% al 100% (0 a 1).
0.01: Error mínimo aceptable de complejidad.
∑ 𝑭𝒊: Son los valores de ajuste de complejidad, donde (1<= i <= 14).
Analizando todas las interfaces que tiene el sistema se obtuvieron los siguientes datos:
PARAMETRO DE MEDIDA CANTIDAD

N° de entradas de usuario 17
N° de salidas de usuario 16
N° peticiones de usuario 18
N° de archivos 13
N° de interfaces externas 3
Tabla 4.1: Parámetros de medida y su cantidad
Una vez obtenida la información de la tabla xx, se procedió a calcular la cuenta total con el
factor de ponderación media, que muestra la siguiente tabla:
PARÁMETRO DE MEDIDA CANTIDAD FACTOR DE PONDERACIÓN TOTAL

N° de entradas de usuario 17 * 4 = 68
N° de salidas de usuario 16 * 5 = 80
N° peticiones de usuario 18 * 4 = 72
N° de archivos 13 * 10 = 130
N° de interfaces externas 3 * 7 = 21
CUENTA TOTAL = 381
Tabla 4.2: Cálculo de la cuenta total
98
La cuenta total de los puntos de función obtenidos se debe ajustar en función a las
características ambientales del sistema. Los valores de ajuste de complejidad Fi basados en las
respuestas a las preguntas formuladas de la siguiente tabla:
Sin influencia
Significativo
Moderado
Nº Factores Fi
Incidental
Esencial
Medio
0 1 2 3 4 5
1 ¿Requiere el sistema copias de seguridad y de recuperación X 5
fiables?
2 ¿Se requiere comunicación de datos? X 5
3 ¿Existen funciones de procesos distribuidos? X 3
4 ¿Es crítico el rendimiento? X 2
5 ¿Sera ejecutado el sistema en un SO existente y fuertemente X 4
utilizado?
6 ¿Requiere el sistema entrada de datos interactiva? X 4
7 ¿Requiere la entrada de datos interactiva que se utilicen varias X 4
pantallas o varias operaciones?
8 ¿Se utilizan los archivos maestros de forma interactiva? X 4
9 ¿Son complejas las entradas, las salidas y/o las peticiones? X 4
10 ¿Es complejo el procesamiento interno? X 5
11 ¿Se ha diseñado el código para ser reutilizable? X 4
12 ¿Están incluidas en el diseño la conversión y la instalación? X 3
13 ¿Se ha diseñado el sistema para soportar diferentes instalaciones X 5

en diferentes organizaciones?
99
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser X 5
fácilmente utilizada por el usuario?
Factor de ajuste de complejidad 57
Tabla 4.3: Valores de ajuste de complejidad
Una vez que se consiguió los valores correspondientes a las variables de la formula de los
puntos función se procedió a realizar el cálculo del mismo.
𝑃𝐹 = 381 ∗ (0.65 + 0.01 ∗ 57)

𝑃𝐹 = 381 ∗ (1.22)
𝑃𝐹 = 464.82
Para comparar los puntos función con su valor máximo, se calculó los puntos función con
los valores de ajuste de complejidad al máximo que es en total el valor 70:
𝑃𝐹 = 381 ∗ (0.65 + 0.01 ∗ 70)

𝑃𝐹 = 381 ∗ (1.35)
𝑃𝐹 = 514.35
Después de haber calculado ambos valores se tiene que la funcionalidad real es:
464.82
𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑 = ( ) ∗ 90 %
514.35
𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑 = 90 %
Este resultado quiere decir que el “Sistema Web para el Control y Seguimiento de Afiliados
a los Entes Gestores Caso: Instituto Nacional de Seguros de Salud INASES”, satisface las
necesidades explicitas e implícitas en un 90% y en un 10% no satisface dichas necesidades.
10
4.1.2 CONFIABILIDAD
La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento
adecuado cuando es utilizando en condiciones específicas, por cierto tiempo. Para este
punto se hizo el análisis del nivel de confiabilidad del sistema, para lo cual primeramente se
considera la confiablidad de cada módulo o subsistema de forma independiente.
Para calcular la confiabilidad de cada módulo se usó de la formula 𝑅(𝑡) = 𝑒−𝜆𝑡.
Donde:
𝑹(𝒕): Confiabilidad de un componente o subsistema t.
𝝀 : Tasa de constantes de fallo (𝜆 = Nº de fallas de acceso/Nº total de accesos al sistema).
𝒕: Periodo de operación de tiempo.
𝒆−𝝀𝒕: Probabilidad de falla de un componente o subsistema en el tiempo t.
Luego de realizar pruebas de cada módulo en un tiempo de 4 horas continuas se logró llenar
la siguiente tabla:
N° Módulo 𝜆 𝑡 𝑅(𝑡)
1 Módulo Seguridad 0.012 4 Hrs. 0.95
2 Módulo Registro 0.022 4 Hrs. 0.92
3 Módulo Planillas 0.025 4 Hrs. 0.90
4 Módulo Control 0.018 4 Hrs. 0.93
5 Módulo Consulta 0.005 4 Hrs. 0.99
Tabla 4.4: valores de confiabilidad de cada modulo
Para calcular la confiabilidad del sistema completo, se vio que si falla la autentificación
(Modulo de seguridad) falla no se puede acceder a los demás módulos, por lo tanto está
conectado en serie con los demás módulos. Y el resto de los modulo están conectados en
paralelo ya que funcionan independientemente de los demás. Es por eso que la
confiabilidad del sistema estaría dada por la fórmula:
𝐶𝑜𝑛𝑓 = 𝑅𝑆 ∗ 𝑅𝑝.
10
Donde: 𝑅𝑠 = 𝑅1 = 0.95 y 𝑅𝑝 5
= ∑𝑖=2 (𝑅𝑖 ∗𝑃𝑖 )
5
∑𝑖=2 𝑃𝑖
En la fórmula de Rp, la variable Pi es la participación del equipo en el desarrollo del módulo

y como la participación fue al 100% = 1se tiene el siguiente resultado:
∑5 𝑅𝑖 0.92 + 0.90 + 0.93 +
0.99 3.74
𝑅𝑝 𝑖 =2 = = 0.94
= 4 = 4
4
Por lo tanto, la confiabilidad del sistema está dada por:
𝐶𝑜𝑛𝑓 = 0.95 ∗ 0.94 = 0.89 = 89%
De lo cual se puede decir que existe un 11% de probabilidad de que el sistema presente
algún fallo cuando se exceda un tiempo de uso continuo, debido a que pueden existir fallas
con la conexión del sistema a la base de datos, conexión del cliente al sistema, uso
incorrecto del sistema por parte del usuario, errores en la entrada de datos.
4.1.3 USABILIDAD
La usabilidad es la capacidad del software de ser entendido, aprendido, y usado de forma
fácil y atractiva. Para determinar el porcentaje de la usabilidad del sistema se optó por
realizar una encuesta a 8 personas. La siguiente tabla nos muestra los resultados de la
encuesta que se realizó:
Respuestas
Nº Pregunta % de si
Si No
1 ¿Aprendió a usar rápido el sistema? 8 2 80
2 ¿Las pantallas que vio fueron de su agrado? 9 1 90
3 ¿Las pantallas que vio fueron fáciles de comprender? 10 0 100
4 ¿El sistema responde rápido a sus solicitudes? 9 1 90
5 ¿El sistema le facilita el trabajo? 9 1 90
6 ¿El sistema reduce su tiempo de trabajo? 10 0 100
7 ¿Es fácil navegar por las distintas opciones? 10 0 100
8 ¿Las operaciones que se realizan no son complicadas? 10 0 100
9 ¿El sistema le proporciono las respuestas requeridas? 9 1 90
10
10 ¿El sistema no presento errores? 9 1 90
PROMEDIO 93
Tabla 4.5: Encuesta sobre la usabilidad del sistema
4.1.4 MANTENIBILIDAD
La Mantenibilidad es la cualidad que tiene el software para ser modificado. Incluyendo
correcciones o mejoras del software, a cambios en el entorno, y especificaciones de
requerimientos funcionales, para poder medir la calidad del mantenimiento del sistema
utilizaremos el índice de madurez del software (IMS), que indica la estabilidad de un
producto de software. El índice de madurez del software se calcula con la siguiente
formula:
𝐼𝑀𝑆 = [𝑀𝑡 − (𝐹𝑎 + 𝐹𝑏 + 𝐹𝑐)]/𝑀𝑡
Donde:
𝑀𝑡 : Número de módulos en la versión actual
𝐹𝑎 : Número de módulos en la versión actual que se han cambiado
𝐹𝑏 : Número de módulos en la versión actual que se han añadido
𝐹𝑐 : Número de módulos en la versión anterior que se han borrado en la versión actual.
Recopilando la información requerida por la formula se obtuvo la información que se
muestra en la siguiente tabla:
Información Valor
𝑀𝑡 5
𝐹𝑎 0
𝐹𝑏 0
𝐹𝑐 0
Tabla 4.6: Información requerida por el IMS
Ahora calculamos el IMS, usando los valores obtenidos:
𝐼𝑀𝑆 = [5 − (0 + 0 + 0)]/5
10
𝐼𝑀𝑆 = 5/5 = 100%
Con ese resultado se concluyó que el Sistema Web para el Control y Seguimiento de
Afiliados a los Entes Gestores Caso: Instituto Nacional de Seguros de Salud INASES, tiene
un índice de madurez de software del 100%.
4.1.5 PORTABILIDAD
La portabilidad es la capacidad que tiene el software para ser trasladado de un entorno a
otro. Para poder medir la portabilidad del sistema usaremos la siguiente formula que indica
el grado de portabilidad que tiene un software.
𝐺𝑃 = 1 − (𝐸𝑇/𝐸𝑅)
Donde:
ET: Es la medida de los recursos necesarios para llevar el sistema a otro entorno.
ER: Es la medida de los recursos necesarios para crear el sistema en el entorno residente.
Si GP > 0, la portabilidad es más rentable que el re-desarrollo
Si GP = 1, la portabilidad es perfecta
Si GP < 0, el re-desarrollo es más rentable que la portabilidad.
Para llevar el sistema web a otro entorno se necesita una memoria extraíble de 8gb o más
capacidad, para crear el sistema en el entorno residente se necesita inicialmente 4
servidores con sistema operativo este puede ser cualquiera (Windows, Linux o Mac OS en
sus diferentes versiones), y servidor Apache, el lenguaje de programación PHP, el gestor de
base de datos MariaDB los cuales deben estar instalados en los servidores.
Con esta información requerida por la fórmula, se procede a calcular el grado de portabilidad:
1
𝐺𝑃 = 1 − ( ) = 1 − 0.14 = 86%
7
Por lo que se concluye que el sistema web tiene un grado de portabilidad del 86%.
10
4.1.6 CALIDAD GLOBAL
Una vez calculado los porcentajes de los diferentes atributos que el sistema web tiene según
lo propuesto por el estándar de calidad ISO 9126, se procedió a calcular la calidad global
del sistema web, la cual se visualiza en la siguiente tabla:
Atributo Valor (%)

Funcionalidad 90
Confiabilidad 89
Usabilidad 93
Mantenibilidad 100
Portabilidad 86
Calidad Global 91.6
Tabla 4.7: Calidad Global del Sistema Web
Con el resultado obtenido se concluyó que la calidad global del Sistema Web para el
Control y Seguimiento de Afiliados a los Entes Gestores Caso: Instituto Nacional de
Seguros de Salud INASES, es del 91.6%.
4.2 SEGURIDAD
La seguridad lógica fue muy importante durante el desarrollo del sistema, se implementó
seguridad lógica en el sistema web, como ser la autenticación de usuarios y la visualización
de las acciones de los usuarios que pertenecen al módulo de seguridad del sistema, para
proteger la información que se traslada entre servidores se usó encriptación, también se
implementó validación para los datos de entrada que tiene el sistema, y finalmente toda la
seguridad del framework PHP yii2.
En cuanto a la seguridad física de la arquitectura del sistema es trabajo de los empleados

del área de informática del instituto nacional de seguros de salud, mantener en buen estado
los equipos físicos de su institución.
10
4.2.1 AUTENTIFICACIÓN
El acceso al sistema al sistema es controlado por la autentificación, en la cual un usuario
debe introducir datos correctos usuario, contraseña y código captcha, estos datos son
validados con código JavaScript de lado del cliente que controla la sintaxis de los campos,
como también código PHP de la del servidor que verifica si los datos introducidos son
correctos. En la siguiente figura se muestra parte del código PHP que captura y valida los
datos introducidos:
Figura 4.1: Fragmento de código de validación JavaScript

4.2.2 SEGUIMIENTO A LAS ACCIONES DE LOS USUARIOS

Una medida de seguridad es el seguir las acciones que realizan todos los usuarios en un
sistema, en el presente proyecto como parte del módulo de seguridad se implementó esta
medida, la cual solo los usuarios administradores del sistema podrán usar. En la siguiente
figura podemos visualizar una captura de la pantalla lista de logs del sistema.
Figura 4.2: Seguimiento a las acciones de usuarios por el sistema

10
4.2.3 ENCRIPTACIÓN
La encriptación de datos es muy importante para proteger los paquetes de información que
se transmiten entre los servidores, en el presente sistema se utilizó algoritmos de
encriptación como el MD5, el algoritmo SHA1 y encriptado AES, en distintas partes de
código del sistema. En la siguiente figura se muestra uno de los algoritmos usados para
encrestar información.
Figura 4.3: Encriptación AES en PHP

Fuente: [PHP, 2015]
4.2.4 SEGURIDAD EN LA BASE DE DATOS

El gestor de base de datos MariaDB, tiene sus propias medidas de seguridad como una
básica autentificación, el manejo de roles, etc. Uno de los ataques más frecuentes realizados
a una base de datos son las inyecciones sql.
Las inyecciones SQL son cadenas de instrucciones SQL que un usuario puede introducir en
cualquier campo de entrada de un formulario. El framework Yii2 está equipado para evitar
este tipo de ataques ya que para hacer consultar este nos pide hacer las consultas por medio
de funciones que pueden ser usadas solamente pos los modelos, estas funciones internas del
framework proveen protección contra las inyecciones SQL y están destinadas a realizar
solo un tipo de acción. En la siguiente tabla se muestra la explicación de las funciones:
FUNCIÓN DESCRIPCIÓN
execute() Para ejecutar un SQL no consulta (como INSERT, DELETE, UPDATE)
queryAll() Ejecuta la sentencia SQL y devuelve todas las filas a la vez.
queryOne() Ejecuta la sentencia SQL y devuelve la una fila del resultado.
Tabla 4.8: Funciones de Seguridad en Yii2
Fuente: [YII, 2015]
10
CAPITULO V
ANÁLISIS DE COSTOS
5.1 MODELO COCOMO II

Modelo COCOMO II, modelo de estimación que se encuentra en la jerarquía de modelos de
estimación de software con el nombre de COCOMO, por Constructive Cost Model
(Modelo Constructivo de Coste). El modelo COCOMO original se ha convertido en uno de
los modelos de estimación de coste del software más utilizados y estudiados en la industria.
a) Características
 Es una herramienta basada en las líneas de código la cual la hace muy poderosa para la
estimación de costos y no como otros que solamente miden el esfuerzo en base al
tamaño.
 Representa el más extenso modelo empírico para la estimación de software.
 Existen herramientas automáticas que estiman costos basados en COCOMO como ser:
Costar, COCOMO 81.
b) Modelos de COCOMO II
Los tres modelos de COCOMO II se adaptan tanto a las necesidades de los diferentes
sectores, como al tipo y cantidad de información disponible en cada etapa del ciclo de vida
de desarrollo, lo que se conoce por granularidad de la información. Estos tres modelos son:
 Modelo de composición de aplicación. Utilizado durante las primeras etapas de la

ingeniería del software, donde el prototipado de las interfaces de usuario, la
interacción del sistema y del software, la evaluación del rendimiento, y la
evaluación de la madurez de la tecnología son de suma importancia.
 Modelo de fase de diseño previo. Utilizado una vez que se han estabilizado los
requisitos y que se ha establecido la arquitectura básica del software.
10
 Modelo de fase posterior a la arquitectura. Utilizado durante la construcción del
software.
5.2 CALCULO DE COSTOS

Para el cálculo del costo total con COCOMO II se usó la herramienta “COCOMO II -
Constructive Cost Model” que pertenece al Centro de Sistemas e Ingeniería de software de
la Universidad de California del Sur.
En el caso del presente proyecto se escogió la opción de estimar el precio total por líneas de
código, y se llenó los datos que requiere el servicio con información obtenida por el equipo
de desarrollo.
Además de la información de líneas de código el modelo requiere varias características

como la flexibilidad de desarrollo, la arquitectura, el trabajo de equipo, tamaño de la base
de datos, complejidad del producto, capacidad del personal, la limitación de tiempo, la
restricción de almacenamiento, el uso de herramientas de software, etc.
Figura 5.1: Inserción de datos para COCOMO II

Fuente: [Herramienta COCOMO II]
10
Después de llenar la información requerida por la herramienta se procedió a calcular y ver
los resultados que nos proporciona la herramienta, lo cual lo podemos visualizar en la
siguiente figura:
Figura 5.2: Resultado de la estimación de costos

Fuente: [Herramienta COCOMO II]
Los resultados que nos proporciona la herramienta son datos importantes, como el esfuerzo
que es 18.9 personas-mes, el tiempo estimado de desarrollo es 9.7 meses, la cantidad de
personas promedio para desarrollar el proyecto es 2 y el costo final del proyecto es 3774$.
Además del costo total del desarrollo que proporciona el modelo COCOMO II, se debería
tomar en cuenta más factores como ser el material de escritorio, internet, mantenimiento,
etc. Dichos factores fueron proporcionados por la institución así que no fue necesario hacer
cálculos adicionales.
Por lo tanto se concluyó que el costo total para desarrollar el proyecto es 3774$, que
convertidos en bolivianos es 26267.04 bs.
11
5.3 BENEFICIO
El VAN y el TIR son dos herramientas financieras procedentes de las matemáticas
financieras que nos permiten evaluar la rentabilidad de un proyecto de inversión,
entendiéndose por proyecto de inversión no solo como la creación de un nuevo negocio,
sino también, como inversiones que podemos hacer en un negocio en marcha, tales como el
desarrollo de un nuevo producto, la adquisición de nueva maquinaria, el ingreso en un
nuevo rubro de negocio, etc.
5.3.1 VALOR ACTUAL NETO (VAN)

El VAN es un método de valoración de inversiones en la que partimos de la rentabilidad
mínima que queremos obtener. Con esta rentabilidad mínima calcularemos el valor
actualizado de los flujos de caja (diferencia entre cobros y pagos) de la operación. Si es
mayor que el desembolso inicial la inversión es aceptable. Interpretación VAN:
 VAN> 0; se recomienda pasar a la siguiente etapa del proyecto
 VAN = 0; es indiferente realizar la inversión
 VAN < 0; se recomienda desecharlo o postergarlo
El van se calcula según la siguiente formula:

𝑛
𝑄𝑖
𝑉𝐴𝑁 = −𝐴 + ∑ 𝑖
𝑖=1 (1 + 𝐾 )
Donde:
Q1, Q2,……, Qn: Flujos de caja
k: Tasa de descuento seleccionada

A: desembolso inicial o inversión inicial
n: vida útil del proyecto
i: período
11
Se calculó el VAN con los siguientes datos:
A=26267.04, k=0.1, n=5 y los flujos de caja que se muestran en la tabla 5.3.
AÑO GASTOS BENEFICIOS FLUJO DE CAJA (BS)

2016 6000 8000 2000
2017 5000 8000 3000
2018 5500 11500 6000
2019 6000 16000 10000
2020 8000 26000 18000
TOTAL 30500 69500 39000
Tabla 5.1. Flujo de caja por años
Fuente: Elaboración propia
Como resultado de los datos se tiene que el VAN es 545.09, notamos que el resultado es
mayor a cero por lo tanto el proyecto es aceptable.
5.3.2 TASA INTERNA DE RETORNO (TIR)

Es una tasa porcentual que indica la rentabilidad promedio anual que genera el capital que
permanece invertido en el proyecto. También se define como la tasa de descuento que hace
que el VAN = 0, su valor no depende del tiempo y representa el máximo costo que el
inversionista podría pagar por el capital prestado.
 TIR > k se recomienda pasar a la siguiente etapa
 TIR = k es indiferente invertir
 TIR < k se recomienda su rechazo o
postergación La TIR se calcula con la siguiente formula:

𝑛
𝑄𝑖
0 = −𝐴 + ∑
(1 +
𝑇𝐼𝑅 )𝑖
Donde: 𝑖=1
Q1, Q2,……, Qn: Flujos de caja

A: desembolso inicial o inversión inicial
n: vida útil del proyecto
11
i: período
Aplicando los datos: A=26267.04, k=0.1 valor estimado de la TIR, n=5 y los flujos de caja
que se muestran en la tabla 5.3, en la fórmula de la TIR se tiene como resultado 10.59%.
Analizando el resultado que es mayor a 0, concluimos que el proyecto se debe realizar.
5.4 COSTO BENEFICIO

Para calcular el costo beneficio usaremos la tabla 5.3 donde encontramos el total de los
ingresos y el total de los beneficios.
𝑇𝑜𝑡𝑎𝑙𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜𝑠 69500
𝐶𝑜𝑠𝑡𝑜 𝑏𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 = =
𝑇𝑜𝑡𝑎𝑙𝐼𝑛𝑔𝑟𝑒𝑠𝑜𝑠 30500
𝐶𝑜𝑠𝑡𝑜 𝑏𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 = 2.28 𝐵𝑠
Del resultado obtenido se concluye que la ganancia por cada boliviano invertido es 1.28bs.
Y de lo cual se concluye que el proyecto es viable.
11
CAPITULO VI
CONCLUSIONES Y RECOMENDACIONES
6.1 CONCLUSIONES
Se logró desarrollar el sistema web para el control y seguimiento del estado de afiliación de
las personas en los entes gestores para el Instituto Nacional de Seguros de Salud, el cual
permite generar certificados de no afiliación como también certificados de afiliación.
Se desarrolló todos los módulos que componen el sistema, los cuales se mencionan a
continuación con una breve descripción:
 Modulo Registro, con el cual el sistema registra o actualiza los datos de empresas
cotizantes y las personas.
 Modulo Consulta, con el cual el sistema puede generar certificados de no afiliación
a y certificados de afiliación vía online, los cuales benefician en tiempo a las
personas bolivianas. Ya que normalmente se tarda un día o más días en adquirir la
certificación, pero con el sistema se genera el certificado en aproximadamente 3
min.
 Modulo Planilla, este módulo genera una planilla para que los empleadores puedan
actualizar la información de sus afiliados y generar planillas de cada mes.
 Modulo Control, con este módulo el sistema puede controlar los accesos que se les
da a los usuarios. Además atenderá solicitudes para actualizar la información de los
beneficiarios, ya que el sistema solo permitirá la afiliación de una persona a un ente
gestor.
 Modulo Seguridad, con el cual el sistema puede mostrar las acciones que realizan
los usuarios en el sistema, es decir si un usuario ingresa al sistema, crea una nueva
planilla, registra un beneficiario, etc. Las acciones podrán ser vistas por un usuario
administrador y además también se cuenta con autentificación de usuarios.
11
El proyecto se desarrolló cumpliendo los objetivos específicos que se plantearon:
 Realizando un análisis del proceso de obtención del certificado de no afiliación en

los entes gestos.
 Determinando los procesos y las herramientas para recolectar la información y
procesar los datos de los beneficiarios.
 Estableciendo las metodologías, las cuales fueron la metodología de desarrollo ágil
SCRUM combinada con la metodología de modelado web UWE, para desarrollar el
sistema web.
 Estableciendo una arquitectura adecuada para distribuir la carga de los servidores.
 Diseñando e implementando los módulos.
 Haciendo cumplir un plan de pruebas y seguridad para el sistema.
De esta manera se concluyó que el objetivo general y los objetivos específicos se

cumplieron satisfactoriamente, de esta manera se desarrolló el sistema web que beneficiara
a las empresas cotizantes, a las personas bolivianas y al instituto nacional de seguros de
salud.
6.2 RECOMENDACIONES
En el proceso de desarrollo del sistema se hizo pruebas unitarias y pruebas de integración,
pero eso no significa que el sistema no tenga errores, por eso se recomienda al instituto que
cuente con personal que haga mantenimiento al sistema para atender posibles errores a
largo plazo.
Si bien se desarrolló exitosamente el módulo de consultas, se recomienda que este se

mejore ya que con la base de datos consolidada se podrá realizar reportes estadísticos
importantes que podrán beneficiar al instituto.
11
BIBLIOGRAFÍA
Referencias Bibliográficas
[LUJAN, 2001] Lujan Mora Sergio. Programación en Internet: Clientes WEB. Edit.: Club
Universitario Publicado en España el 2001.
[GARCIA, 2013] García Chi Rosa Imelda. Guía Técnica de Ingeniería Web. Instituto
Tecnológico de ciudad Valles 2013.
[CAMPS, 2005] Camps Rafael, Casillas Luis, Costal Dolors. Base de datos. Eureca Media.
Universidad Oberta de Catalunya mayo 2005.
[PERALTA, 2003] Peralta Adriana. Metodología SCRUM. Universidad ORT Uruguay.

Facultad de Ingeniería. 2003.
[PRESSMAN, 2005] Pressman Roger, “Ingeniería del Software”. ed. mcgraw-hill /

interamericana de mexico 2005.
[CANOS, 2000] Canos José, Letelier P. “Metodologías Ágiles en el Desarrollo de

Software”. Universidad Politécnica de Valencia. España 2000.
Decretos
[D.S. Nº23716] BOLIVIA. Instituto Nacional de Seguros de Salud. 1994. Decreto Supremo
Nº 23716. Creación del INASES.
[D.S. Nº25798] BOLIVIA. Instituto Nacional de Seguros de Salud. 1994. Decreto Supremo
Nº 25798. Marco legal del INASES.
Tesis y Proyectos
[ALANDIA, 1997] Alandia M. Cintia G. 1997. Sistema de Afiliación y Servicios médicos

para una caja de salud. Universidad Mayor de San Andrés.
[VILA, 2004] Vila C. María V. 2004. Sistema de Registro y Control de Afiliación –

Seguro Social Universitario. Universidad Mayor de San Andrés.
11
[COPA, 2004] Copa H. Pablo G. 2004. Sistema de afiliación y Control de afiliación –
Caja Petrolera de Salud. Universidad Mayor de San Andrés.
[LUJAN, 2008] Lujan T. Paola H. 2008. Sistema de información y afiliación vía web
del Seguro de Salud para el adulto mayor - Dirección de Salud
Gobierno Municipal de el Alto
[CITON, 2006] Citón María Laura. 2006. Método ágil scrum aplicado al desarrollo de
un software de trazabilidad – Universidad de Mendoza
[JEREZ, 2004] Jerez Lugo, Carlos Augusto. 2004. Seguridad para lograr Confiabilidad
y Calidad de los Servicios Digitales en Internet - Universidad de las
Américas Puebla.
[BORGHELLO, 2001] Borghello Cristian F. 2001. Seguridad Informática - Implicancias e

Implementación
[NUÑEZ, 2010] Nuñez Jose. 2010. Usabilidad en Metodologías Agiles. Universidad

Politécnica De Madrid.
Sitios Web y Materiales Electrónicos
[ALBALADEJO, 2013] Albaladejo Xavier. Como gestionar proyectos con Scrum. [En línea]
[Disponible en:] <http://www.proyectosagiles.org/que-es-scrum>
[Consulta 9 julio 2015]
[GALIANO, 2012] Galiano Francesco. “Desarrollo Ágil de Software”. [En línea]

[Disponible en:] <http://frayu.blogspot.com/2012/09/desarrollo-agil-
de-software.html> [Consulta 08 octubre 2015]
[LMU, 2000] LMU – Ludwig-Maximilians-Universität München. UWE – UML –

base Web Engineering. [En línea] [Disponible en:]
<http://uwe.pst.ifi.lmu.de/teachingTutorial.html> [consulta 10 julio
2015]
11
[LÓPEZ, 2009] López Eliazar. Arquitectura de n capas. [En línea] [Disponible en:]
<https://www.academia.edu/10102692/Arquitectura_de_n_capas>
[Consulta 18 septiembre 2015]
[IBM, 2013] IBM Knowledge Center. “Introduction to DB2 for z/OS”. [En línea]
[Disponible en:] <http://www-01.ibm.com/support/knowledgecenter/
SSEPEK_10.0.0/com.ibm.db2z10.doc.intro/src/tpc/db2z_whatisdb2.di
ta?lang=es > [Consulta 19 agosto 2015]
[MICROSOFT, 2008] Microsoft. Database Mirroring Overview. [En línea] [Disponible en:]
<https://technet.microsoft.com/en-us/library/ms189852(v=sql.105)
.aspx> [Consulta 20 agosto 2015]
[W3SCHOOLS, 2015] The world's largest web developer site. [En línea] [Disponible en:]
<http://www.w3schools.com/ > [Consulta 16 de octubre de 2015].
[YII2, 2015] Página Oficial de Framework YII2. [En línea] [Disponible en:]
<http://www.yiiframework.com/wiki/?tag=yii2> [Consulta 15 de
octubre de 2015].
[MARIADB, 2015] Página Oficial de MariaDB. [En línea] [Disponible en:]

<https://mariadb.com> [Consulta 17 de octubre de 2015].
[WEBARCHIVE, 2015] Internet Archive Wayback Machine. Investigación IT – Forks de

MySQL. [En línea] [Disponible en:] <http://web.archive.org/web/
20121203042114/http://investigacionit.com.ar/forks-de-mysql>
[Consulta 17 de octubre de 2015].
[ANGELFIRE, 2012] Angelfire. ¿Qué es la Ingeniería de Software?. [En línea] [Disponible

en:] <http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware
.html> [Consulta 9 de octubre de 2015]
11
[LETELIER, 2006] Patricio Letelier. Metodologías ágiles para el desarrollo de software:
eXtreme Programming (XP). [En línea] [Disponible en:]
<http://www.cyta.com.ar/ta0502/v5n2a1.htm> [Consulta 10 de octubre
de 2015]
[ROMERO, 2011] Romero M. Andrés. Aspectos Básicos de la Seguridad en Aplicaciones

Web. [En línea] [Disponible en:] <http://www.seguridad.unam.mx/
documento/ ?id=17> [Consulta 10 de octubre de 2015].
[TENNESSEE, 2015] The University of Tennesse, Knoxville. [En línea] [Disponible en:]
<https://help.utk.edu/kb/index2.php?func=show&e=1699> [Consulta
19 agosto 2015]
[ECURED, 2015] EcuRed Conocimiento con todos y para todos. Servidor HTTP
Apache. [En línea] [Disponible en:] <http://www.ecured.cu/
Servidor_HTTP_Apache> [Consulta 23 agosto 2015]
[SONCCO, 2008] Soncco Araujo Lewis M. Tecnología Web. Pontificia Universidad

Católica del Perú. [En línea] [Disponible en:]
<http://es.slideshare.net/MeliVidal/tecnologia-web-5778008>
[Consulta 10 de julio de 2015].
[SUPERSALUD, 2015] Superintendencia de Salud. Gobierno de chile. [En línea] [Disponible

en:] http://www.supersalud.gob.cl/servicios/576/w3-article-5586.html
[Consulta 10 de julio de 2015].
[SBS, 2015] Superintendencia de banca, seguros y afp. República del Perú. [En
línea] [Disponible en:] <http://www.sbs.gob.pe/usuarios/categoria/
consulta-de-afiliados/250/c-250> [Consulta 10 de julio de 2015].
11
ANEXOS
12
ANEXO A – ARBOL DE PROBLEMAS
Demora en los trámites de afiliación o reafiliación

No cumplimiento
Las personas puedenconestar
el afiliados a más de un ente gest
reglamento de afiliación,
desafiliación y reafiliación
El proceso de obtener un certificado de no afiliación a distintos entes gestores es manual y lenta.
Una persona debe ir a cada ente gestor a consultar

Los enteselgestores
estado de
noafiliación
trabajan que La información de los afiliados a los entes gestores no es in
tiene.centralizada
de forma
Cada ente gestor maneja la información de sus afiliados independientemente de otras.

ANEXO B – ARBOL DE OBJETIVOS
Control en tiempo real sobre el estado de afiliación de c

Acorta el tiempo de obtención del certificación de no afiliación
Desarrollar un sistema web para el control y seguimiento del estado de afiliación de las personas en los en
Consulta vía web del estado de afiliación de cada persona en tiempo real Integrar la información de los afiliados en los entes gesto
ANEXO C – MARCO LÓGICO
Título: Sistema Web para el control y seguimiento de afiliados a los entes gestores
Indicadores Objetivamente Medio de Suposiciones

Resumen Narrativo
Verificables Verificación Importantes
Mejorar el control y seguimiento % de tiempo para conseguir Sistema web

de afiliados certificado de no afiliación concluido, para
Optimizar el tiempo de conseguir disminuido verificar la mejora de

Objetivo General
un certificado de no afiliación. % de tiempo para el control y los indicadores
o Meta
seguimiento de afiliados
disminuido
Implementar un sistema web para El tiempo para hacer el debido Documento del perfil Voluntad de los jefes de la
el control y seguimiento del control y seguimiento a de proyecto de grado institución.
Objetivo del estado de afiliación de las afiliados en entes gestores será Implementación de los Voluntad política del
Proyecto personas en los entes gestores óptimo. módulos gobierno.
para el Instituto Nacional de
Seguros de Salud.
Desarrollar un módulo de registro La gestión de usuarios del Seguimiento del Buen desempeño del
en el cual se podrá registrar entes sistema será rápida y confiable cliente al proyecto. equipo de desarrollo del
Resultados gestores, empresas cotizantes y Consultar el estado de Documento del perfil sistema web.
las personas. afiliación de una persona será de proyecto de grado Voluntad del líder de
confiable. equipo de desarrollo.
Desarrollar un módulo de Se podrán actualizar los datos Pruebas a los módulos Los equipos (servidores)
consulta con el cual se podrá de n afiliados en el sistema. avanzados. para implementar todo el
generar certificados de no El sistema podrá generar Versionamiento del sistema deben funcionar
afiliación a los distintos entes reportes de confianza y con sistema en gitblit. correctamente.
gestores vía online. calidad. Voluntad de los jefes de la
Desarrollar un módulo de La base de datos tendrá contara institución.
planillas con el cual se podrá con seguridad lógica a varios
generar una planilla para que los niveles.
empleadores puedan actualizar la
información de sus afiliados.
Desarrollar un módulo de control

con el cual se podrá controlar los
accesos que se les da a los
usuarios, y atender solicitudes de
cambio de datos.
Desarrollar un módulo de
seguridad el cual protegerá la
información del sistema.
Para alcanzar los resultados se Equipos computacionales Seguimiento del tutor Buen desempeño del
tendrá que realizar las siguientes Personas que conformaran el y revisor al proyecto equipo de desarrollo del
etapas de desarrollo con sus equipo de desarrollo Documento del perfil sistema web.
Actividades actividades: de proyecto de grado Voluntad del líder de

Persona que represente al
Planificación.- en la cual sacamos instituto como cliente. Pruebas al código equipo de desarrollo.
los requisitos (Product Backlog) realizado
Información de distintas
fuentes: libros, internet y otros.
Análisis.- se crea la El instituto debe pagar una Información de la El instituto debe proveer
documentación (Sprint Planning) remuneración al equipo de bibliografía. información al equipo de
Diseño.- se diseña las partes del desarrollo. desarrollo.
sistema (Sprint Planning) Correcto funcionamiento
Construcción y pruebas.- se de los equipos
construye el sistema, se hacen computacionales
pruebas y reuniones con el cliente

(Sprint backlog, Scrum Daily
Meeting, Sprint review,
Retrospective)
ANEXO D – EJEMPLO DE CERTIFICADO DE NO AFILIACION DE LA CAJA
NACIONAL DE SALUD
ANEXO E – HOJA DONDE SE ENCUENTRA EL ARTICULO 14 DEL
REGLAMENTO DE AFILIACIÓN, DESAFILIACIÓN Y REAFILIACIÓN

Sistema Web Control-Desbloqueado

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema Web Control-Desbloqueado

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y

MENCION: INGENIERIA DE SISTEMAS INFORMATICOS

POSTULANTE: JOSE MANUEL LOZA TROCHE

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

A mi mAdre AlEJANDRA Troche, por DARme lA VidA, por quererme

espERAr NADA A CAmbio, todo esto te lo debo A ti. GRACIAs MAMÁ.

A mi pAdre JUAn CArlos LoZA, por ensEÑARMe el vAlor de LA

persevERANCIA, por ensEÑARMe A ser fuerte Ante los problemAs, y por

hAberme DADO UNA EDUCACIón excelente. GRACIAs PApÁ.

A mi ABUELA Mercedes SullCAtA (Q.E.P.D.) y mi tÍA RAquelin Troche

(Q.E.P.D.), porque en vIDA me motivAron A perseguir mis sueños y

porque me desmostRAron su cAriño. MuchAs gRACIAs.

A mis hERMAnos EFRAÍN LoZA y DAniel LoZA, por hAberme ApoYADO en

sITUACIones difíciles, y por DARme motivos pARA sAlir AdelAnte juntos.

Agradecer primeramente al Ing. Julio Prieto Peñaranda y al Lic. Roger Navia

Gutiérrez, por apoyarme constantemente en la elaboración de este proyecto y

más que todo por su amistad.

Agradecer a mi tutor M.Sc. Aldo Ramiro Valdez Alvarado quien me ha

orientado en todo momento en la realización de este proyecto.

Agradecer a mi asesora Lic. Brigida Alexandra Carvajal Blanco, por su

dedicación de tiempo, por sus correcciones y aportes que fueron importantes

para la finalización de este trabajo.

Agradecer a las personas que me apoyaron, me motivaron, y me contribuyeron

en la finalización de este proyecto.

Y finalmente agradezco a los juegos Warcraft y Starcraft por haberme

inspirado y motivado a estudiar la carrera de informática.

El sistema web fue desarrollado bajo la metodología de desarrollo ágil de software

1.2.1 ANTECEDENTES INSTITUCIONALES

 Caja Nacional de Salud.

Algunos conceptos importantes que se dan a continuación se manejan con frecuencia:

 AFILIACIÓN.- Registro de empresas, instituciones e inscripción del trabajador,

 DESAFILIACIÓN.- Proceso que deben seguir las empresas e instituciones a

 REAFILIACIÓN.- Proceso determinado mediante Resolución Administrativa

 ENTE GESTOR DE SALUD.- Persona Jurídica de derecho público

 TRABAJADOR ASEGURADO.- Es aquella persona, sea obrero, empleado o

 BENEFICIARIOS.- Los miembros de la familia del asegurado protegidos por las

 PRESTACIONES.- Beneficios otorgados en especie y/o en dinero por el Seguro

El INASES en su calidad de entidad fiscalizadora a los entes gestores (seguros de salud a

1.2.2 PROYECTOS SIMILARES

 “SISTEMA DE AFILIACION Y SERVICIOS MEDICOS PARA UNA CAJA DE

 “SERVICIO SUPER EN LINEA” .- Servicio del sistema web de la

1.3.1 PROBLEMA CENTRAL

La información que obtiene la persona demuestra que dicha persona no se encuentra

Por las razones ya mencionadas surge la siguiente pregunta:

¿Cómo se podrá agilizar el proceso de obtener un certificado de no afiliación a

 La cantidad de beneficiarios se aproxima a los 4 millones, es por eso que el control

1.4 DEFINICIÓN DE OBJETIVOS

1.4.1 OBJETIVO GENERAL

1.4.2 OBJETIVOS ESPECÍFICOS

1.6 ALCANCES Y LÍMITES

A continuación se mencionan algunos beneficios que se obtendrán:

2.1 INGENIERIA DE SOFTWARE

2.1.1 METODOLOGIAS DE DESARROLLO

2.1.1.1 METODOLOGIAS DE DESARROLLO AGILES

Las metodologías agiles son un marco conceptual de la ingeniería de software que

 Al individuo y las iteraciones del equipo de desarrollo sobre el proceso y las

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que

VII. El software que funciona es la medida principal de progreso.