Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Sistema Web Control-Desbloqueado
Sistema Web Control-Desbloqueado
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
2015
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LICENCIA DE USO
mucho, por creer en mí, por ApoYARme, esTAndo siempre dispuesTA sin
GRACIAs.
AGRADECIMIENTOS
…. 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).
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
acciones de usuarios...........................................................................................................................57
Figura 3.6: Diagrama de Navegación de los requisitos Autentificación de Usuarios y Mostrar
acciones de usuarios...........................................................................................................................58
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
entes gestores y Generar Certificado de afiliación a un ente gestor..................................................80
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..................................................81
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.7: Sprint Backlog 2................................................................................................................56
Tabla 3.8: Pruebas unitarias del sprint 2............................................................................................60
Tabla 3.9: Sprint Backlog 3................................................................................................................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.13: Sprint Backlog 5..............................................................................................................72
Tabla 3.14: Pruebas unitarias del sprint 5..........................................................................................78
Tabla 3.15: Sprint Backlog 6..............................................................................................................79
Tabla 3.16: Pruebas unitarias del sprint 6..........................................................................................82
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
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:
3
enfermedad, maternidad y riesgos profesionales de Corto Plazo establecidos en el
Código de Seguridad Social y disposiciones legales conexas.
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:
5
1.3 PLANTEAMIENTO DEL PROBLEMA
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”.
6
1.3.2 PROBLEMAS SECUNDARIOS
A continuación se mencionan los problemas identificados:
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.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.
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
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]
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].
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]
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:
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:
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.
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.
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.
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.
“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.
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.
15
Pocos artefactos. Más artefactos.
Menos énfasis en la arquitectura del software. La arquitectura del software es esencial y se expresa
mediante modelos.
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]
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:
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.
18
función de esto el equipo puede trabajar para acelerar o desacelerar el trabajo para
cumplir con la fecha de entrega.
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.
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.
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.
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.
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.
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).
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.
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 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..
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.
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 la sesión no está sincronizado, el servidor espejo está disponible como un servidor
de reserva (con posible pérdida de datos). [MICROSOFT, 2008]
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].
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:
26
Una aplicación web se puede ejecutar en distintas plataformas (hardware y sistema
operativo).
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.
Según [BORGHELLO, 2001], los objetivos que se plantea la seguridad logica son:
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.
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:
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
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 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.
30
Los casos de uso de la aplicación y sus relaciones
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.
Estereotipo Uso
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.
32
Y en la siguiente tabla se muestra el uso de cada estereotipo:
Estereotipo Uso
<<index>> Usado para listar una cantidad de objetos del mismo tipo.
<<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.
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:
Estereotipo Uso
<<presentationAlternatives>> Nos indica que ese conjunto de elementos puede visualizarse de diferentes
maneras.
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.
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]
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
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.
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.
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.
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.
40
Los beneficios de MariaDB sobre MySQL son notables, a continuación se enumera los más
importantes:
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.
42
3.2 PRE JUEGO
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:
4 Mostrar Acciones de Muy Alta 4 días Ver la lista de acciones que nos
Usuarios muestra el sistema
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.
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.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.
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.
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:
usuarios
certificado varchar(255) certificado que se le da al usuario cada vez que se loguea, para
controlar que ingrese solo desde un navegador,
49
id_serv int id del servidor al que se conecta el usuario
log
servidores
entegestor
50
aclusrgroup
estado int puede tener el valor 1 cuando la relación está activa o 0 inactivo
aclgroup
aclnaccesos
aclapp
51
estado int puede tener el valor 1 cuando está activa o 0 inactivo
empleador
planilla
atributo tipo descripción
52
Fechaaceptado timestamp fecha y hora en la que se acepta la planilla
planillabeneficiario
codigoplanilla varchar(70) código único que consta del empleador de: emp-<idemp>-
<fechacreacion>
codigoempleador varchar(50) código único del empleado que consta de: emp-<idemp>-
<fechacreacion>
53
fechasesantia timestamp fecha de sesantia, fecha límite para que el beneficiario pueda
cotizar a su ente gestor
beneficiario
atributo tipo descripción
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.
3.3.1.3 PRUEBAS
Se hizo las pruebas unitarias al servidor de base de datos donde se implementó la base de
datos.
55
3.3.2 SPRINT 2
3.3.2.1 PLANIFICACIÓN
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:
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:
b) Modelo de Contenidos
Se diseñó el diagrama de contenido para los requisitos “Autentificación de Usuarios” y
“Mostrar Acciones de Usuarios”, el cual se lo visualiza en la siguiente figura:
c) Modelo de Navegación
Se diseñó el diagrama de navegación para los requisitos “Autentificación de Usuarios” y
“Mostrar Acciones de Usuarios”, el cual se lo visualiza en la siguiente figura:
57
Figura 3.6: Diagrama de Navegación de los requisitos Autentificación de
Usuarios y Mostrar acciones de usuarios.
Fuente: [Elaboración propia]
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.
58
Figura 3.8: Diagrama de Presentación del Sistema Web.
Fuente: [Elaboración propia]
59
3.3.2.3 PRUEBAS
Después de codificar, se hizo las pruebas unitarias al módulo de seguridad desarrollado.
3 La Lista de Logs (acciones) de los usuarios nos muestra todos los datos Cumple
requeridos en el diagrama de presentación.
Tabla 3.8: Pruebas unitarias del sprint 2
Fuente: [Elaboración propia]
3.3.3 SPRINT 3
3.3.3.1 PLANIFICACIÓN
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.
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
a) Modelo de Requerimientos
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:
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.
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.
63
Figura 3.15: Modelo de Presentación de Crear/Actualiza Beneficiarios.
Fuente [Elaboración propia]
64
3.3.3.3 PRUEBAS
Después de codificar, se hizo las pruebas unitarias al módulo de registro desarrollado.
3.3.4 SPRINT 4
3.3.4.1 PLANIFICACIÓN
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.
65
Pruebas 11/09/2015 11/09/2015 Completado
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
Pruebas 18/09/2015 18/09/2015 Completado
Tabla 3.11 Sprint Backlog 4
Fuente: [Elaboración Propia]
3.3.4.2 DESARROLLO
Después de diseñar el Sprint Backlog 4, inmediatamente se empezó a diseñar los modelos
UWE de cada requisito para luego pasar a la fase de codificación de los mismos.
a) Modelo de Requerimientos
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:
b) Modelo de Contenidos
Se diseñó el diagrama de contenidos para los requisitos “Generar/Actualizar Planillas” y
“Generar Reportes de las planillas”, el cual se lo visualiza en la siguiente figura:
66
Figura 3.18: Diagrama de Contenidos de los requisitos Generar/Actualizar
Planillas y Generar Reportes de las planillas
Fuente: [Elaboración propia]
c) Modelo de Navegación
Se diseñó el diagrama de navegación para los requisitos “Generar/Actualizar Planillas” y
“Generar Reportes de las planillas”, el cual se lo visualiza en la siguiente figura:
67
d) Modelos de Presentación
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.
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 generar planilla, lista de planillas, planilla
beneficiarios que se subdivide en formulario beneficiario y lista de beneficiarios, y
finalmente el reporte planilla PDF.
68
Figura 3.21: Diagrama de Presentación de Lista de Planillas.
Fuente [Elaboración propia]
La siguiente figura nos muestra el diagrama de presentación de planilla beneficiarios que
pertenece al requisito “Generar/Actualizar Planillas”.
69
La siguiente figura nos muestra el diagrama de presentación de listar beneficiarios que
pertenece al requisito “Generar/Actualizar Planillas”.
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
3.3.5 SPRINT 5
3.3.5.1 PLANIFICACIÓN
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.
71
Administrar
Privilegios de
Pruebas 05/10/2015 05/10/2015 Completado
Usuarios
3.3.5.2 DESARROLLO
Después de diseñar el Sprint Backlog 5, inmediatamente se empezó a diseñar los modelos
UWE de cada requisito para luego pasar a la fase de codificación de los mismos.
a) Modelo de Requerimientos
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:
72
b) Modelo de Contenidos
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:
73
La siguiente figura nos muestra el diagrama de navegación de administrar menus.
74
La siguiente figura nos muestra el diagrama de navegación de administrar solicitudes de
cambio de datos de beneficiarios.
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 administrar menús que se compone de 3
formularios, asignar grupos que se divide en lista de usuarios y grupos de usuario.
75
Figura 3.30: Diagrama de Presentación de la Administración de Usuarios.
Fuente [Elaboración propia]
76
Figura 3.33: Diagrama de Presentación del Formulario Acceso.
Fuente [Elaboración propia]
La siguiente figura nos muestra el diagrama de presentación lista de usuarios.
77
La siguiente figura nos muestra el diagrama de presentación asignar grupos.
78
3.3.6 SPRINT 6
3.3.6.1 PLANIFICACIÓN
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.
3.3.6.2 DESARROLLO
Después de diseñar el Sprint Backlog 6, inmediatamente se empezó a diseñar los modelos
UWE de cada requisito para luego pasar a la fase de codificación de los mismos.
a) Modelo de Requerimientos
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
Fuente: [Elaboración propia]
b) Modelo de Contenidos
Se diseñó el diagrama de contenidos 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:
80
c) Modelo de Navegación
Se diseñó el diagrama de navegación 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:
81
La siguiente figura nos muestra el diagrama de presentación del certificado único de
afiliación.
3.3.6.3 PRUEBAS
Después de codificar, se hizo las pruebas unitarias al módulo de registro desarrollado.
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.
2 El sistema lista las acciones que hicieron los usuarios en cualquier módulo. Cumple
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.
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) 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.
84
Figura 3.42: Pantalla de autentificación
Fuente: [Elaboración propia]
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.
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.
86
Figura 3.45: Pantalla del Formulario de Beneficiario
Fuente: [Elaboración propia]
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.
87
Figura 3.47: Pantalla de Generar una nueva Planilla
Fuente: [Elaboración propia]
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.
88
Figura 3.49: Pantalla del Formulario de Beneficiario en Planillas
Fuente: [Elaboración propia]
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.
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.
90
Figura 3.52: Pantalla de Administrar Menús
Fuente: [Elaboración propia]
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.
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.
93
Figura 3.58: Pantalla del formulario de Certificado
Fuente: [Elaboración propia]
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
Fuente: [Elaboración propia]
95
CAPITULO IV
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:
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 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).
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:
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
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
Fuente: [Elaboración Propia]
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.
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.
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
Fuente: [Elaboración Propia]
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 𝑃𝑖
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
Fuente: [Elaboración Propia]
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
Fuente: [Elaboración Propia]
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:
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.
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:
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.
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
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.
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 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.
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.
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:
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.
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.
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%.
𝑇𝑜𝑡𝑎𝑙𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜𝑠 69500
𝐶𝑜𝑠𝑡𝑜 𝑏𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑜 = =
𝑇𝑜𝑡𝑎𝑙𝐼𝑛𝑔𝑟𝑒𝑠𝑜𝑠 30500
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:
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.
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.
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
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.
[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]
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].
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]
[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]
[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
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
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
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.