Sistema de Control de Personal Siskav

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

“BOLIVIA”
TRABAJO DE GRADO
SISTEMA DE CONTROL DE PERSONAL APLICANDO LA

ARQUITECTURA ORIENTADA A SERVICIOS INTEGRADO CON
DISPOSITIVO BIOMÉTRICO. CASO DE ESTUDIO: GOBIERNO
MUNICIPAL AUTÓNOMO DE COCHABAMBA.
YESMANI FERNANDEZ ARAMBULO
COCHABAMBA 2014
ESCUELA MILITAR DE INGENIERÍA
MCAL. ANTONIO JOSÉ DE SUCRE
“BOLIVIA”
TRABAJO DE GRADO
SISTEMA DE CONTROL DE PERSONAL APLICANDO LA

ARQUITECTURA ORIENTADA A SERVICIOS INTEGRADO CON
DISPOSITIVO BIOMÉTRICO. CASO DE ESTUDIO: GOBIERNO
MUNICIPAL AUTÓNOMO DE COCHABAMBA.
YESMANI FERNANDEZ ARAMBULO
Modalidad: Proyecto de Grado

presentado como requisito
parcial para optar al título de
Licenciado en Ingeniería de
Sistemas.
TUTOR: LIC. MSC. DUNIA SOLIZ TORRICO.
COCHABAMBA 2014
Dedicatoria:
A mi familia en especial a mis padres Delia Arámbulo y

Romelio Fernández, que depositaron toda su confianza para
que culmine exitosamente mi formación académica en la
Escuela Militar de Ingeniería.
YesmaniFernández
Agradecimientos.
A Dios, por darme la salud, sabiduría, inteligencia, capacidad y sobre todo fuerza para
concluir este proyecto.
A toda mi familia, por el apoyo incondicional, que me brindaron en el transcurso de mi vida.
A mi madre Delia por brindarme su comprensión durante mis estudios para poder hacer
realidad mis sueños.
A mis hermanas Yesenia, Yohana, por brindarme una mano amiga o una palabra de aliento
cuando la necesitaba, por transformar una lágrima en una sonrisa.
A mis tíos Carlos Pinto, Julieta Arámbulo, por brindarme su apoyo incondicional en los
momentos que más necesitaba.
A mis docentes, por ser pacientes en sus enseñanzas e impartir todos sus conocimientos para
mi formación, quienes a lo largo de los conocimientos brindados a lo largo de estos 5 años
permitieron que el resultado del presente proyecto sea satisfactorio y de la base para un
excelente desenvolvimiento profesional.
A mi querida tutora Lic. M.Sc. Dunia Soliz, por ser tan buena, amable, tolerante y paciente
conmigo, por el esfuerzo y compromiso puesto en este proyecto, que gracias a sus
motivaciones logró superara las expectativas esperadas, pero sobre todo por las enseñanzas y
lecciones aprendidas a lo largo de todo este proceso.
A la docente de taller de grado Ing. M.Sc. Yanina Galaburda por todo el apoyo brindado
en la realización del proyecto, buscando siempre el resultado de excelencia.
A mis revisores Ing. Verónica Sasha e Lic. Ivan Fernández, al Cnl. Roberto Estrada, Cnl
Jason Fuentes, Gral. Brig. Jerry Toranzo por todo el tiempo dedicado y por no permitir
tener un paso en falso a lo largo del proyecto, confiando siempre en los resultados de
excelencia.
Al personal administrativo, a los oficiales de la carrera de ingeniería de sistemas de la

Escuela Militar de Ingeniería quienes a lo largo de los conocimientos brindados durante estos
5 años me apoyaron con unas palabras de aliento.
Y a todos los que con un granito de arena, construyeron un castillo para logre ser un
persona de bien y con objetivos en la vida. Mil gracias
Yesmani Fernández Arámbulo

RESUMEN EJECUTIVO
El Sistema de Control de Personal aplicando la Arquitectura Orientada a Servicios e

integrado al dispositivo biométrico permite reducir el tiempo invertido en el proceso
de control de asistencia e identificación de los funcionarios públicos aplicando en el
proceso un dispositivo biométrico que acelera la identificación de los funcionarios de
la institución y brinda seguridad a la misma para evitar duplicidad de identidad,
disminuye los errores en la elaboración de los reportes respectivos ya que se
encuentran integrados todos los subsistemas principales.
Por lo tanto, se facilita la obtención de los reportes y además se obtienen reportes

clasificados actualizados para la información del personal de la institución.
En el primer capítulo perteneciente a generalidades se describen los antecedentes,

la problemática en el proceso de control de personal, así también se realizó la
propuesta de un sistema integrado para la resolución de los problemas identificados
en la situación problemática a través del objetivo general y objetivos específicos para
dar solución a las necesidades de la empresa.
El segundo capítulo contiene toda la investigación teórica necesaria que se realizó

para desarrollar el SISKAV (Sistema de kardex, asistencia y vacaciones), entre los
que podemos mencionar modelos de desarrollo de software, lenguajes de
programación, gestores de Base de Datos, Arquitectura Orientada a Servicios,
Tecnología biométrica, Servicios web, seguridad, tipos de generación y exportación
de reportes, y las pruebas de software. Posteriormente se realizó un análisis de
ventajas y desventajas para determinar el uso del modelo de desarrollo incremental,
las herramientas de programación (C#, Visual Studio 2010, .Net, Crystal Reports), el
gestor de base de datos Oracle 11g y una selección del dispositivo biométrico a
utilizar.
El tercer capítulo comprende toda la etapa de desarrollo en el cuál se emplea el

modelo de desarrollo incremental, donde se describe la selección de las
herramientas a utilizarse, se elaboró el modelado de negocio actual (Proceso de
kardex, Subsistema de asistencia, subsistema de vacaciones), dando paso al diseño
del modelado alternativo por actores del sistema en el cuál se proponen las mejoras
reparando las deficiencias actuales de la institución. A partir de los incrementos
planificados se realizó el análisis de requerimientos, el diseño (casos de uso,
colaboración, clases, diagrama de base de datos, Arquitectura Orientada a
Servicios) que dieron paso al desarrollo de los módulos del sistema.
Cabe resaltar que al diseñar y codificar los módulos respectivos para cada
subsistema se hizo uso de los componentes de la Arquitectura Orientada a
Servicios, mediante la implementación de servicios web (SOAP, XML, WSDL, UDDI).
Para ello se pusieron en marcha los diferentes servicios (Kardex, Asistencia,

Vacaciones, biométrico) que se comunican con la base de datos, lo que permite
realizar consultas de inserción, selección y actualización en las bases de datos.
Finalizado el desarrollo del sistema se realizó la demostración de la hipótesis a
través de la demostración de las variables establecidas en la hipótesis del proyecto,
para poder demostrar que el sistema cumple con lo planteado y se logran beneficios
para la institución.
En el capítulo cuarto referente al análisis de viabilidad, se ha realizado un estudio de

diferentes factores participantes en el desarrollo del proyecto. La viabilidad técnica
permitió determinar la tecnología necesaria para implementar el sistema propuesto.
En la viabilidad económica se determinó el costo de los elementos necesarios en

hardware y software conjuntamente con la mano de obra para el desarrollo del
sistema, y por último, en la viabilidad operativa se determinó si la propuesta cumple
con las expectativas del usuario y los objetivos planteados en el primer capítulo.
En el quinto capítulo se describen las conclusiones referidas a cada objetivo

planteado, así como las recomendaciones las cuales son: algunas para mejorar el
funcionamiento del sistema a futuro y otras para que el sistema funcione de la
manera descrita en el presente documento.
ÍNDICE DE CONTENIDO.
TÍTULO Pág.
CAPITULO 1. GENERALIDADES
1.1. INTRODUCCIÓN. ......................................................................................... 1
1.2. ANTECEDENTES..................................................................................... ...3
1.3. PLANTEAMIENTO DEL PROBLEMA ………………………………………... 7
1.3.1. Identificación del problema. .......................................................................... 7
1.3.1.1. Identificación de la situación problemática. .................................................. 7
1.3.1.2. Identificación de las causas. ......................................................................... 8
1.3.2. Formulación del problema. ........................................................................... 8
1.3.3. Análisis causa efecto. ................................................................................... 8
1.4. OBJETIVOS Y ACCIONES. ......................................................................... 9
1.4.1. Objetivo General. .......................................................................................... 9
1.4.2. Objetivos específicos y acciones. ................................................................. 9
1.5. JUSTIFICACIÓN. ....................................................................................... 16
1.5.1. Justificación Técnica................................................................................... 16
1.5.2. Justificación Económica. ............................................................................ 16
1.5.3. Justificación Social. .................................................................................... 16
1.6. ALCANCE. ................................................................................................. 17
1.6.1. Alcance Temático. ...................................................................................... 17
1.6.2. Alcance Institucional. .................................................................................. 17
1.6.3. Alcance Temporal. ...................................................................................... 17
1.6.4. Alcance Geográfico. ................................................................................... 17
1.7. HIPÓTESIS. ............................................................................................... 18
1.7.1. Análisis de Variables. ................................................................................. 18
1.7.2. Definición Conceptual. ................................................................................ 18
1.7.3. Operativización de variables....................................................................... 20
1.8. MATRIZ DE CONSISTENCIA. ................................................................... 21
2.1. MÉTODOS Y TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN. ........ 22
2.1.1. Métodos interactivos. .................................................................................. 22
2.1.1.1. Entrevistas………………………………………………………………………. 22
i
2.1.1.2. Cuestionarios…………………………………………………………………… 27
2.1.2. Métodos no intrusivos. ................................................................................ 30
2.1.2.1. Muestreo………………………………………………………………………… 30
2.1.2.2. Investigación……………………………………………………………………. 30
2.1.2.3. Observación…………………………………………………………………….. 30
2.2. ARQUITECTURA ORIENTADA A SERVICIOS. ........................................ 30
2.2.1. Capas de software. ..................................................................................... 31
2.2.2. Principios de La Arquitectura Orientada a Servicios. .................................. 32
2.2.3. Implementación de la Arquitectura Orientada a Servicios. ......................... 33
2.2.4. Roles de La Arquitectura Orientada a Servicios. ........................................ 33
2.2.5. Tecnologías y estándares de la Arquitectura Orientada a Servicios. ......... 34
2.2.6. Facilitadores tecnológicos clave de SOA.................................................... 35
2.2.7. Servicios Web. ............................................................................................ 37
2.2.7.1. Pila de interoperabilidad……………………………………………………….. 38
2.2.7.2. .NET y servicios Web………………………………………………………….. 41
2.2.7.3. Creación de un servicio web………………………………………………….. 42
2.2.7.4. Enfoque solicitud de servicio…………………………………………………. 44
2.2.7.5. Enfoque proveedor de servicios. ……………………………………………...45
2.2.7.6. Estructura y funcionamiento de la aplicación. ……………………………….46
2.2.7.7. Funcionamiento de un servicio web. ………………………………………….47
2.3. TECNOLOGÍA BIOMÉTRICA. ................................................................... 49
2.3.1. Sistemas biométricos.................................................................................. 49
2.3.2. Tipos de dispositivos biométricos en el mercado. ...................................... 54
2.3.3. Funcionamiento de los dispositivos biométricos. ........................................ 56
2.3.4. Dispositivos biométricos de Control de Acceso y Asistencia. ..................... 58
2.3.4.1. TR-ICLOCK 260………………………………………………………………... 58
2.3.4.2. iFace402………………………………………………………………………… 58
2.3.4.3. DigitalPersona………………………………………………………………….. 59
2.4. INGENIERÍA DE SOFTWARE. .................................................................. 60
2.4.1. Modelos de Desarrollo de software. ........................................................... 61
2.4.1.1. Modelo de proceso incremental………………………………………………. 61
ii
2.4.1.2. Modelo de Proceso Unificado ………………………………………………….62
2.4.1.3. Modelo de Espiral……………………………………………………………......64
2.4.2. UML. ........................................................................................................... 66
2.4.2.1. Diagramas UML………………………………………………………………… 67
2.4.3. Tipos de Pruebas ....................................................................................... 68
2.4.3.1. Estrategias de prueba para software convencional ……………………….68
2.5. TECNOLOGÍAS DE DESARROLLO. ........................................................ 73
2.5.1. Lenguajes de programación. ...................................................................... 73
2.5.1.1. C# con ASP.NET……………………………………………………………….. 74
2.5.1.2. Java……………………………………………………………………………… 76
2.5.1.3. Php………………………………………………………………………………. 78
2.5.2. IDE (Integrated Development Environment). .............................................. 79
2.5.2.1. Visual Studio. ...………………………………………………………………….79
2.5.2.2. NetBeans. ………………………………………………………………………..80
2.5.2.3. Eclipse. …………………………………………………………………………..82
2.5.3. Frameworks. ............................................................................................... 83
2.5.3.1. CodeIgniter. ……………………………………………………………………83
2.5.3.2. .NET. ……………………………………………………………………………..83
2.5.3.3. Java Server Faces. ……………………………………………………………..85
2.5.4. Mecanismos de seguridad. ......................................................................... 85
2.5.4.1. SHA-512. ………………………………………………………………………85
2.5.4.2. Log’s de usuarios con C# y Oracle. …………………………………………..86
2.5.5. Generadores de Reportes. ......................................................................... 86
2.5.5.1. Agata. …………………………………………………………………………….86
2.5.5.2. Crystal Reports. …………………………………………………………………86
2.5.5.3. Codisa Query Builder. ………………………………………………………….87
2.6. SISTEMAS DE GESTIÓN DE BASES DE DATOS. .................................. 87
2.6.1. SQL Server. ................................................................................................ 87
2.6.2. Oracle. ........................................................................................................ 88
2.6.3. MySQL........................................................................................................ 90
iii
3.1. DISEÑO DEL MODELADO DE NEGOCIO ACTUAL PARA EL
PROCESO DE CONTROL DE PERSONAL. ............................................. 93
3.1.1. Diseño del modelado de negocio actual para el control de kardex. ............ 93
3.1.2. Diseño del modelado de negocio actual para el control de asistencia........ 97
3.1.3. Diseño del modelado de negocio actual para el control de vacaciones.... 100
3.2. DISEÑO DEL MODELO DE NEGOCIO ALTERNATIVO
CONSIDERANDO LAS VENTAJAS QUE OFRECE UN SISTEMA
WEB PARA EL PROCESO DE CONTROL DE PERSONAL. ................. 103
3.2.1. Evaluación de las deficiencias existentes en el proceso actual. ............... 103
3.2.2. Diseño del Modelo de negocio alternativo para el proceso de control de
personal. ................................................................................................... 104
3.2.3. Selección del modelo de desarrollo de Software. ..................................... 107
3.2.4. Plan de incrementos para el desarrollo del software. ............................... 109
3.3. DESARROLLO DEL SUBSISTEMA DE ADMINISTRACIÓN DE
KARDEX BASADO EN COMPONENTES DE LA ARQUITECTURA
ORIENTADA A SERVICIOS. ................................................................... 110
3.3.1. Análisis. .................................................................................................... 110
3.3.2. Diseño. ..................................................................................................... 123
3.3.2.1. Selección del lenguaje de programación, Framework e IDE. ................... 127
3.3.2.2. Selección del Sistema de gestión de Base de datos. ............................... 129
3.3.3. Código. ..................................................................................................... 140
3.3.4. Pruebas. ................................................................................................... 148
3.4. DISEÑO E IMPLEMENTACIÓN DEL SUBSISTEMA DE CONTROL
DE ASISTENCIA, CON EL MÓDULO DE ASIGNACIÓN DE
HORARIOS DE INGRESO Y SALIDAS DEL PERSONAL
INTEGRADO CON EL SUBSISTEMA DE ADMINISTRACIÓN DE
KARDEX. ................................................................................................. 154
3.4.1. Análisis. .................................................................................................... 154
3.4.2. Diseño ...................................................................................................... 162
3.4.3. Pruebas. ................................................................................................... 166
iv
3.5. DESARROLLO DEL SUBSISTEMA DE VACACIONES INTEGRADO
CON EL SUBSISTEMA DE CONTROL DE ASISTENCIA ...................... 169
3.5.1. Análisis. .................................................................................................... 169
3.5.2. Diseño ...................................................................................................... 174
3.5.3. Pruebas. ................................................................................................... 178
3.6. INTEGRACIÓN DEL SISTEMA BASADO EN ARQUITECTURA
ORIENTADA A SERVICIOS CON DISPOSITIVO DE CONTROL
BIOMÉTRICO. .......................................................................................... 179
3.6.1. Selección de dispositivo biométrico. ......................................................... 179
3.6.2. Análisis. .................................................................................................... 180
3.6.3. Diseño ...................................................................................................... 186
3.6.4. Código. ..................................................................................................... 190
3.6.5. Pruebas. ................................................................................................... 192
3.7. IMPLEMENTACIÓN DE MECANISMOS PARA LA GENERACIÓN Y
EXPORTACIÓN DE REPORTES DE VERIFICACIÓN DE CONTROL
DE KARDEX, ASISTENCIA Y VACACIONES. ........................................ 193
3.7.1. Análisis. .................................................................................................... 193
3.7.2. Diseño ...................................................................................................... 198
3.7.3. Arquitectura del sistema completo. ........................................................... 203
3.7.4. Código. ..................................................................................................... 204
3.7.5. Pruebas. ................................................................................................... 205
3.8. PRUEBAS DE VERIFICACION DE FUNCIONAMIENTO DEL
SISTEMA. ................................................................................................. 206
3.8.1. Pruebas Unitarias. .................................................................................... 206
3.8.2. Pruebas de Integración............................................................................. 209
3.9. DEMOSTRACIÓN DE LA HIPÓTESIS. ................................................... 211
3.9.1. Demostración de la primera variable dependiente. .................................. 212
3.9.2. Demostración de la segunda variable dependiente. ................................. 215
3.9.3. Demostración de la tercera variable dependiente. ................................... 218
3.9.4. Demostración de la variable independiente. ............................................. 221
3.9.4.2. Cálculo del estadístico T. ……………………………………………………..225
v
4.1. VIABILIDAD TECNICA. ........................................................................... 228
4.2. VIABILIDAD ECONOMICA. ..................................................................... 230
4.2.1. Estimación de coste del producto ............................................................. 230
4.2.2. Estimación de gastos en Software y Hardware ........................................ 236
4.2.3. Análisis beneficio-costo. ........................................................................... 240
4.3. VIABILIDAD OPERATIVA. ...................................................................... 243
5.1. CONCLUSIONES. .................................................................................... 245
5.2. RECOMENDACIONES. ........................................................................... 248
BIBLIOGRAFÍA ………………………………………………………………………….251
vi
ÍNDICE DE TABLAS.
TÍTULO Pág.
Tabla 1: Objetivos específicos y acciones. ............................................................... 10
Tabla 2: Operativización de variables. ...................................................................... 20
Tabla 3: Identificación de características y deficiencias de los sistemas actuales. . 103
Tabla 4: Descripción de las ventajas y desventajas de los modelos de
desarrollos de software. ......................................................................... 107
Tabla 5: Documentación del caso de uso ingresar al sistema. ............................... 114
Tabla 6: Documentación del caso de uso administrar usuarios. ............................. 115
Tabla 7: Documentación del caso de uso administrar datos del personal. ............. 117
Tabla 8: Documentación del caso de uso administrar documentación. .................. 118
Tabla 9: Documentación del caso de uso administrar cargo................................... 120
Tabla 10: Descripción de las ventajas y desventajas de los lenguajes de
programación. ...................................................................................... 127
Tabla 11: Descripción de las ventajas y desventajas de los sistemas de gestión
de base de datos. ................................................................................... 130
Tabla 12: Diccionario de datos de la tabla usuarios. ............................................... 133
Tabla 13: Diccionario de datos de la tabla personal. .............................................. 134
Tabla 14: Diccionario de datos de la tabla documentación. .................................... 136
Tabla 15: Diccionario de datos de la tabla cargo. ................................................... 137
Tabla 16: Pruebas para el caso de uso ingresar al sistema. ................................... 148
Tabla 17: Pruebas para el caso de uso administrar usuarios. ................................ 149
Tabla 18: Pruebas para el caso de uso administrar datos del personal. ................. 150
Tabla 19: Pruebas para el caso de uso administrar documentación. ...................... 152
Tabla 20: Pruebas para el caso de uso administrar cargo. ..................................... 153
Tabla 21: Documentación del caso de uso administrar asistencia. ......................... 157
Tabla 22: Documentación del caso de uso administrar permisos. .......................... 158
Tabla 23: Diccionario de datos de la tabla registro. ................................................ 164
Tabla 25: Pruebas para el caso de uso administrar asistencia. .............................. 167
Tabla 26: Pruebas para el caso de uso administrar permisos. ............................... 168
vii
Tabla 27: Documentación del caso de uso administrar permisos. .......................... 172
Tabla 28: Diccionario de datos de la tabla boleta. .................................................. 177
Tabla 29: Pruebas para el caso de uso administrar vacaciones. ............................ 178
Tabla 30: Pruebas para el caso de uso administrar vacaciones. ............................ 179
Tabla 31: Documentación del caso de uso administrar huellas. ............................. 183
Tabla 32: Diccionario de datos de la tabla biométrico. ............................................ 190
Tabla 33: Pruebas para el caso de uso administrar huellas. ................................... 192
Tabla 34: Características de los reporteadores. ..................................................... 196
Tabla 35: Ventajas y desventajas de los tipos de exportación. ............................... 197
Tabla 36: Diccionario de datos de la tabla personal. .............................................. 200
Tabla 38: Diccionario de datos de la tabla permisos. .............................................. 201
Tabla 39: Diccionario de datos de la tabla boleta. .................................................. 202
Tabla 40: Pruebas para el caso de uso generar y exportar reportes. ..................... 206
Tabla 41: Comparación de tiempos en los procesos. ............................................. 212
Tabla 42: Comparación de cantidad de errores. ..................................................... 215
Tabla 43: Comparación de tipos de reportes. ......................................................... 218
Tabla 44: Tabla comparativa de beneficios del sistema propuesto. ........................ 222
Tabla 45: Tabla de requerimientos mínimos para la construcción del software
(Cliente - Servidor). ................................................................................ 228
Tabla 46: Valores constantes por modo de desarrollo ............................................ 231
Tabla 47: Ecuación básica del esfuerzo en COCOMO (Modelo Intermedio y
Detallado). .............................................................................................. 231
Tabla 48: Ecuación básica del tiempo en COCOMO (Modelo Intermedio). ............ 232
Tabla 49: Factores de Costo en COCOMO. ........................................................... 233
Tabla 50: Estimado de coste de software y hardware ............................................ 237
Tabla 51: Costos de requerimientos para la institución........................................... 239
Tabla 52: Detalle de los costos. .............................................................................. 241
viii
ÍNDICE DE FIGURAS.
TÍTULO Pág.
Figura 1: Matriz de consistencia. .............................................................................. 21
Figura 2: Intercambios entre el uso de preguntas abiertas y cerradas. .................... 29
Figura 3: Tecnologías de implementación de la SOA. .............................................. 33
Figura 4: Roles en los servicios Web........................................................................ 34
Figura 5: Facilitadores tecnológicos clave de SOA................................................... 36
Figura 6: Pila de protocolos de los Servicios Web.................................................... 38
Figura 7: Pila de interoperabilidad de los servicios Web. ......................................... 39
Figura 8: Los servicios Web en Funcionamiento. ..................................................... 40
Figura 9: Estructura de los mensajes. ...................................................................... 41
Figura 10: Creación, registro, búsqueda y utilización de un Servicio Web. .............. 43
Figura 11: Solicitud de servicio. ................................................................................ 45
Figura 12: Proveedor de servicios. ........................................................................... 46
Figura 13: Estructura de un servicio Web. ................................................................ 47
Figura 14: Funcionamiento de un servicio Web. ....................................................... 48
Figura 15: Funcionamiento de los dispositivos biométricos. ..................................... 57
Figura 16: El modelo incremental. ............................................................................ 61
Figura 17: Ciclo de vida del Proceso Unificado. ....................................................... 63
Figura 18: Modelo de espiral común......................................................................... 65
Figura 19: Prueba de unidad. ................................................................................... 70
Figura 20: Entorno de prueba de unidad. ................................................................. 71
Figura 21: Diagrama de modelado de negocio actual de control de kardex. ............ 93
Figura 22: Diagrama de modelado de negocio actual de control de asistencia. ....... 97
Figura 23: Diagrama de modelado de negocio actual de control de vacaciones. ... 101
Figura 24: Diagrama de modelado de negocio alternativo del Administrador del
sistema. ................................................................................................ 104
Figura 25: Diagrama de modelado de negocio alternativo del Encargado de
RR.HH. ................................................................................................. 105
Figura 26: Diagrama de modelado de negocio alternativo del Funcionario público.106
Figura 27: Actores del primer incremento. .............................................................. 112
ix
Figura 28: Casos de uso del sistema del primer incremento. ................................. 113
Figura 29: Diagrama de caso de uso administrador del sistema. ........................... 122
Figura 30: Diagrama casos de uso encargado RR.HH. .......................................... 123
Figura 31: Diagrama de colaboración ingresar al sistema. ..................................... 123
Figura 32: Diagrama de colaboración administrar usuarios.................................... 124
Figura 33: Diagrama de colaboración administrar datos del personal. ................... 124
Figura 34: Diagrama de colaboración administrar documentación. ........................ 125
Figura 35: Diagrama de colaboración administrar cargo. ....................................... 125
Figura 36: Diagrama de clases del primer incremento. .......................................... 126
Figura 37: Diseño de la base de datos utilizando Oracle data modeler. ................. 133
Figura 38: Componentes de la Arquitectura Orientada a Servicios. ....................... 138
Figura 39: Aplicación de la arquitectura orienta a servicios en el subsistema de
control de asistencia. ............................................................................ 139
Figura 40: Creación de un servicio web. ................................................................ 141
Figura 41: Configuraciones y WebMethod por defecto. ......................................... 142
Figura 42: Contratos del servicio web. ................................................................... 142
Figura 43: Verificación del servicio web. ................................................................ 143
Figura 44: Agregar referencia del servicio web. ..................................................... 144
Figura 45: Instancia del servicio web en un aplicación ........................................... 144
Figura 46: Interfaz de bienvenida del sistema. ....................................................... 145
Figura 47: Interfaz de registro de usuarios. ............................................................ 146
Figura 48: Administración de usuarios.................................................................... 146
Figura 49: Registro de datos del personal. ............................................................. 147
Figura 50: Administración de documentación. ........................................................ 147
Figura 51: Actores del segundo incremento. .......................................................... 155
Figura 52: Casos de uso del sistema del segundo incremento. ............................. 156
Figura 53: Diagrama de casos de uso encargado de RR.HH. ................................ 160
Figura 54: Diagrama de caso de uso Funcionario. ................................................. 161
Figura 55: Diagrama de colaboración administrar asistencia. ................................ 162
Figura 56: Diagrama de colaboración administrar permisos................................... 162
Figura 57: Diagrama de clases del segundo incremento. ....................................... 163
x
Figura 59: Actores del tercer incremento. ............................................................... 170
Figura 60: Casos de uso del sistema del tercer incremento. .................................. 171
Figura 61: Diagrama casos de uso encargado RR.HH........................................... 173
Figura 62: Diagrama casos de uso Funcionario. .................................................... 174
Figura 63: Diagrama de colaboración administrar vacación. .................................. 174
Figura 64: Diagrama de clases del tercer incremento. ........................................... 175
Figura 66: Actores del cuarto incremento. .............................................................. 181
Figura 67: Casos de uso del sistema del cuarto incremento. ................................. 182
Figura 68: Diagrama casos de uso encargado RR.HH........................................... 185
Figura 69: Diagrama casos de uso Funcionario. .................................................... 186
Figura 70: Diagrama de colaboración administrar datos del personal. ................... 186
Figura 71: Diagrama de colaboración administrar asistencia. ................................ 187
Figura 72: Diagrama de colaboración administrar huellas. ..................................... 187
Figura 73: Diagrama de clases del cuarto incremento. .......................................... 188
Figura 75: Creación de un servicio web. ................................................................ 191
Figura 76: Configuraciones y Web Method. ........................................................... 191
Figura 77: Actores del quinto incremento. .............................................................. 194
Figura 78: Casos de uso del sistema del quinto incremento. ................................. 195
Figura 79: Diagrama de clases del quinto incremento. ........................................... 198
Figura 81: Arquitectura del sistema completo......................................................... 203
Figura 82: Exportación de reportes en CrystalReports. .......................................... 205
Figura 83: Verificación de las pruebas unitarias para el subistema de kardex. ...... 207
Figura 84: Verificación de las pruebas unitarias para el subsistema de asistencia. 208
Figura 85: Verificación de las pruebas unitarias para el subsistema de
vacaciones. .......................................................................................... 208
Figura 86: Integración de servicios web para la obtención de reportes. ................. 210
Figura 87: Reporte en gridview. .............................................................................. 220
xi
Figura 88: Reporte en Reportviewer. ...................................................................... 220
Figura 89: Reporte en CrystalReports. ................................................................... 221
Figura 90: Campana de Gauss para la aceptación de la hipótesis. ........................ 227
xii
ÍNDICE DE ANEXOS.
TÍTULO Pág.
ANEXO A ................................................................................................................ 254
ANEXO B ................................................................................................................ 255
ANEXO C ................................................................................................................ 256
ANEXO D ................................................................................................................ 267
ANEXO E ................................................................................................................ 270
ANEXO F ................................................................................................................ 273
xiii
1.1. INTRODUCCIÓN.
En un mundo tan intercomunicado en el que vivimos, rodeado de miles de sistemas,

con funcionalidades dispersas y un gran número de posibles consumidores de esas
funcionalidades, se hace imprescindible estar al tanto de lo que se esconde detrás de
la Arquitectura Orientada a Servicios.
Rigurosamente, SOA se define como una estrategia TI que organiza las funciones de
las aplicaciones empresariales en servicios, basados en una serie de estándares,
que permite reutilizarlos y combinarlos para cubrir una serie de necesidades de
negocio (JIbarra, 2014).
Esto puede sonar un poco complicado y complejo, sin embargo, no tiene otro objetivo
que mostrar al exterior los distintos servicios o funcionalidades que una empresa o
institución puede llegar a ofrecer al que le interese o necesite hacer uso de estos.
Esta arquitectura, tiene muchas ventajas. Para empezar una de ellas es el costo,
porque aunque desplegar un sistema basado en SOA en una empresa relativamente
grande no es tarea sencilla, una vez se ponga en marcha permitirá a esa empresa
ser mucho más eficiente, mucho más reutilizable en lo que a sus funciones de
negocio se refiere, y mucho más simple a nivel tecnológico.
Los servicios web, muy nombrados en los últimos tiempos en el mundo del software,
es una de las posibles aproximaciones o implementaciones de SOA, y proporcionan
una solución técnica. Serán los servicios web los que ofrezcan al exterior esas
funcionalidades de negocio de cualquier empresa.
La arquitectura de SOA es una respuesta directa a las necesidades de las áreas de

negocios que desean disponer de más ﬂexibilidad en los sistemas de la empresa
para poder modiﬁcar más rápidamente los procesos como consecuencia de peligros
u oportunidades que surgen en el entorno.
1 de 274
SOA está basado en tecnologías desarrolladas inicialmente para realizar
operaciones B2B (Business to Business) pero que se han revelado muy útiles dentro
de la intranet.
En la actualidad las instituciones públicas y privadas atraviesan por una renovación

de las estrategias de control de personal, debido a los avances tecnológicos que con
el transcurrir de los años avanza a pasos agigantados creando nuevas opciones para
que las empresas o instituciones mejoren el control de personal.
En muchos casos las instituciones gubernamentales carecen de medios que les

permitan controlar el personal, unos de estos casos es el Gobierno Municipal
Autónomo de Cochabamba (G.M.A.C.).
Existen una gran variedad en métodos y medios de gestión de asistencia y

permanencia del personal, desde el control de asistencia que se realiza con registros
manuales en libros de asistencia, a los sistemas de marcación de reloj en tarjetas de
cartón, pasando por el uso de tarjetas magnéticas, sistemas biométricos, etc. Todos
pensados para el control de asistencia y control del cumplimiento del horario de
trabajo, aplicables a cualquier tipo de institución, desde instituciones públicas a
privadas pasando por las Alcaldías y gobernaciones.
En el ámbito de las tecnologías de la seguridad, uno de los problemas fundamentales

a solventar es la necesidad de autenticar de forma segura la identidad de las
personas que pretenden acceder a un determinado servicio o recinto físico. De este
modo, surge la biometría, también conocida como técnicas de identificación
biométrica, con el objetivo de resolver este problema a partir de características que
son propias de cada individuo, como voz, huella dactilar, rostro, etc. (Internet, 2013).
La biometría es una herramienta poderosa. Se rige por métodos automatizados de

reconocimiento, basados en características fisiológicas o de comportamiento. Las
tecnologías aplicadas más comunes en este campo explotan el reconocimiento de
voz, iris, sistemas dactilares y faciales, geometría de manos, olor corporal,
reconocimiento del ADN, la forma de la oreja, etc. (Accesor, 2014).
2 de 274
Las huellas dactilares, las retinas, el iris, los patrones faciales, las de venas de la
mano o la geometría de la palma de la mano, representan ejemplos de
características biométricas (Accesor, 2014).
Después del ADN, las huellas digitales constituyen la característica humana más
singular, la probabilidad de que dos personas tengan la misma huella digital es 1/ 67
billones (Biometricsid, 2013).
1.2. ANTECEDENTES.
La Ciudad de Cochabamba, fue fundada el 23 de Enero de 1826, durante la llegada

del Mariscal Antonio José de Sucre, este creó el edificio de la Alcaldía Municipal de
Cochabamba, para la cancelación de bienes e inmuebles, territorio e impuestos en
todo el municipio, la misma que tiene una estructura de estilo renacentista, que con
el trascurrir del tiempo ha sido muy bien conservado, las instalaciones quedan
ubicadas en la Plaza 14 de Septiembre en la acera noroeste.
El Gobierno Municipal Autónomo de Cochabamba (G.M.A.C.) se divide en seis

comunas o subalcaldías: Comuna Tunari, Comuna Molle, Comuna Valle Hermoso,
Comuna Alejo Calatayud, Comuna Itocta y La Comuna Adela Zamudio.
Esta entidad cuenta con gran cantidad de empleados públicos, los cuales trabajan en
las diferentes Direcciones como ser: Dirección de género y generacional, Desarrollo
Económico, Oficialía Superior de Cultura, Dirección especial de protección de la
Madre tierra, Turismo y Catastro. Todas estas direcciones trabajan con una
documentación de gran importancia, es así que el Municipio de Cercado trabaja con
grandes volúmenes de información.
Desde que se iniciaron las actividades en la alcaldía esta contó con personal en las
diferentes oficialías ya mencionadas.
Toda persona para ingresar a trabajar en la institución, debe cumplir

satisfactoriamente con los procesos de evaluación y selección establecidos por el
Sub-sistema de Administración de Personal, para posteriormente, procesar el
3 de 274
contrato de trabajo con las cláusulas respectivas y de acuerdo a las modalidades que
se establece el reglamento Interno de personal (VER ANEXO C).
Toda persona que sea contratada por la institución, estará sujeta al período de
prueba de 89 días calendario, establecido por disposiciones legales, durante el cual,
se efectuarán las evaluaciones correspondientes. Dentro del período de prueba y
antes de los quince días de su conclusión, el jefe inmediato superior bajo
responsabilidad funcionaria, deberá enviar un informe a la Dirección Administrativa y
de Recursos Humanos, en el que se evaluará su desempeño y se recomendará la
contratación permanente o no de la persona sujeta al período de prueba.
De resolverse la contratación en forma indefinida, se comunicará al postulante esta

decisión por medio de un memorándum, aprobado y firmado por la Máxima Autoridad
Ejecutiva.
Los procesos que se requieren evaluar para el proyecto se describen a continuación:
Del Kardex de personal:
La Unidad de recursos humanos, en su área de archivos, es la encargada de la

recepción de los documentos personales, al momento del ingreso de cada uno de los
funcionarios públicos, cuando estos son contratados deben apersonarse al área de
archivos a dejar su documentación personal, la encargada verifica realizando un
tiqueo en la lista de requisitos para el archivo personal (VER ANEXO A). Este
proceso se realiza para cada uno de los funcionarios y de forma manual, al finalizar
la revisión, la encargada guarda toda la documentación verificada con la lista de
requisitos evaluada. Posteriormente la encargada almacena los archivadores en los
diferentes armarios.
Al contar con mucho volumen de folders almacenados en los armarios, se crea el

problema de extravío de información, lo cual genera molestia en los funcionarios ya
que estos deben presentar su documentación nuevamente.
4 de 274
Del Control de asistencia:
Dentro de la unidad de Recursos Humanos, también se realiza el control de

asistencia de todo el personal de la municipalidad de Cochabamba, esta unidad vela
porque los funcionarios cumplan con sus horas de trabajo, el cual es para el turno de
la mañana de 8:00 a 12:00 y por la tarde de 14:30 a 18:30.
El personal del municipio trabaja ocho horas diarias y cuarenta horas semanales
según establece la Ley del Trabajo en su artículo 46 (VER ANEXO B). La carga
horaria es de cuatro horas por la mañana y cuatro horas por la tarde, con un
descanso de dos horas y media.
Los encargados del control de asistencia cuentan con un sistema de escritorio

desarrollado en Visual Basic con conexión a SQL Server, este no se encuentra unido
a los lectores biométricos sino que trabaja de manera independiente, cuya función es
imprimir los reportes de planillas de asistencia del personal.
Por otra parte el sistema tiene limitaciones en su funcionamiento referidos al

procesamiento semanal en lo que concierne a la relación entre el sistema y los
relojes, por lo que no puede generar reportes clasificados de la asistencia del
personal.
El personal de la institución no puede abandonar sus labores durante la jornada de

trabajo, sin previa autorización del superior inmediato como manda el Articulo 25 del
Reglamento Interno de Personal. (VER ANEXO C).
Todo el personal tiene la obligación de registrar personalmente la hora de ingreso y

de salida de la institución como lo establece el artículo 26. (VER ANEXO C).
El Responsable de Registro de Asistencia, recibe el reporte de control de asistencia

conjuntamente con sus respaldos del control de personal de las diferentes comunas
y direcciones hasta el 23 de cada mes, ya que la asistencia se calcula del 21 de cada
mes al 20 del siguiente mes, en base a lo recibido, realiza una inspección de los
reportes de control de asistencia de cada uno de los servidores públicos y
5 de 274
trabajadores municipales, coteja con los respaldos recibidos según informe remitido a
la Dirección de Recursos Humanos, para luego registrar en la planilla general de
asistencia, para finalmente firmar y remitir al Jefe (a) del Dpto. de Administración de
Personal.
De las Vacaciones:
Los directores de cada unidad, presentan a la Dirección Administrativa y de Recursos

Humanos, la programación de vacaciones anual del personal que se encuentra bajo
su cargo, el mismo que deberá ser formulado en coordinación con el mencionado
personal, a fin de no perjudicar el normal desarrollo de las actividades de la
institución.
El Rol de vacaciones Anual, deberá contemplar mínimamente la programación del

uso del 50% de la vacación del servidor público, quedando el restante 50% en forma
opcional para casos de emergencia.
Los servidores públicos de la institución, tienen derecho de hacer uso de su vacación

anual, el uso de la vacación anual es obligatorio para todos los servidores públicos
de la institución, ésta no puede ser acumulada por más de dos períodos anuales,
salvo el caso de existir una imperiosa necesidad de acuerdo al Artículo 33 del
Decreto Reglamentario de la Ley General del Trabajo, la institución concede licencia
a los servidores públicos, siempre que a su juicio exista una razón justificada y
debidamente comprobada, las licencias pueden ser: con goce de haber , Sin goce de
haber, con cargo a vacación (VER ANEXO C artículos 34,35,40 al 42).
La encargada de realizar las boletas de vacaciones del personal cuenta con un

sistema desarrollado en Visual Basic, en el cual registra los datos del funcionario
para posteriormente imprimir las boletas de vacación.
Así mismo cuando un funcionario solicita vacaciones recoge una boleta del área de
recursos humanos donde indica la fecha que este quiere salir de vacaciones y los
días que solicita, luego esta boleta es presentada a su jefe de unidad para su
correspondiente autorización o denegación. Cuando se autoriza la vacación a un
6 de 274
funcionario hay que tomar en cuenta que este no marcara horario de ingreso ni de
salida.
1.3. PLANTEAMIENTO DEL PROBLEMA.
A continuación se mencionarán los siguientes puntos para poder determinar el

problema de forma clara.
1.3.1. Identificación del problema.
A partir de las entrevistas y observaciones realizadas, se ha identificado el siguiente

problema. Para el proceso de control de personal, el almacenamiento de los kardex
de los funcionarios se realiza de forma manual, el sistema de control de ingreso no
se encuentra integrado a los lectores biométricos y el sistema de vacaciones no
cumple con los requerimientos que exige la institución según el reglamento interno
de personal y la Ley General del Trabajo.
1.3.1.1. Identificación de la situación problemática.
 El almacenamiento del kardex del personal se realiza de forma manual en

armarios llegando a extraviarse en algunos casos por el descuido de la
encargada.
 Cuando se requiere la documentación del kardex de un funcionario, la
búsqueda se realiza de forma manual, revisando en los diferentes
armarios, lo cual conlleva pérdida de tiempo y molestias en la persona que
lo necesita.
 El sistema de control de asistencia que considera el reglamento interno de
personal y La Ley de Trabajo, trabaja de forma independiente y aislada,
ocasionando que los reportes generados por este, no sean lo
suficientemente coherentes con los reportes de las planillas de asistencia.
 El sistema de vacaciones solo permite una impresión de las boletas de
vacaciones para cada individuo, carece de reportes clasificados para todo
el personal, provocando deficiencias en el control y seguimiento de
7 de 274
vacaciones y doble registro en el sistema de asistencia y en el de
vacaciones.
1.3.1.2. Identificación de las causas.
Las causas identificadas en la situación problemática son:
 El almacenamiento del kardex del personal se realiza de forma manual en

armarios.
 Cuando se requiere la documentación del kardex de un funcionario, la
búsqueda se realiza de forma manual, revisando en los diferentes
armarios.
 El sistema de control de asistencia que considera el reglamento interno de
personal y La Ley de Trabajo, trabaja de forma independiente y aislada.
 El sistema de vacaciones solo permite una impresión de las boletas de
vacaciones para cada individuo y carece de reportes clasificados para todo
el personal.
1.3.2. Formulación del problema.
Los ineficientes procedimientos manuales, limitaciones técnicas y funcionamiento

aislado de los sistemas existentes aplicados en el proceso de control de personal del
Gobierno Municipal Autónomo de Cochabamba, provocan retardo en el
procesamiento de la información, posibilidad de cometer errores en el proceso de
transcripción a planillas oficiales, molestia por parte del personal, tareas repetitivas y
duplicadas, incumplimiento del reglamento interno de personal y de la Ley General
del Trabajo (VER ANEXO C).
1.3.3. Análisis causa efecto.
El análisis causa efecto es descrito a continuación:
Causa:
 Los ineficientes procedimientos manuales.
8 de 274
 Limitaciones técnicas.
 Funcionamiento aislado de los sistemas existentes.
Efecto:
 Retardo en el procesamiento de la información.

 Posibilidad de cometer errores en el proceso de transcripción a planillas
oficiales.
 Molestia por parte del personal.
 Tareas repetitivas y duplicadas.
 Incumplimiento del reglamento interno de personal y de la Ley General
del Trabajo (VER ANEXO C).
1.4. OBJETIVOS Y ACCIONES.
1.4.1. Objetivo General.
Desarrollar un sistema de control de personal aplicando la Arquitectura Orientada a

Servicios integrado con dispositivo biométrico, para obtener información de manera
rápida, registro de datos coherentes con el reglamento interno de personal y la Ley
del Trabajo. Caso de Estudio: Gobierno Municipal Autónomo de Cochabamba.
1.4.2. Objetivos específicos y acciones.
 Analizar el proceso de control de kardex, asistencia y vacaciones y diseñar

el modelado de negocio actual.
 Diseñar el modelo de negocio alternativo considerando las ventajas que
ofrece una arquitectura orientada a servicios para el proceso de control de
personal.
 Desarrollar el subsistema de administración de kardex basado en
componentes de la Arquitectura Orientada a Servicios.
 Diseñar e implementar el subsistema de control de asistencia, con el
módulo de asignación de horarios de ingreso y salidas del personal
integrado con el subsistema de administración de kardex.
9 de 274
 Desarrollar el subsistema de vacaciones integrado con el subsistema de
control de asistencia.
 Integrar el sistema basado en Arquitectura Orientada a Servicios con
dispositivo de control biométrico.
 Implementar mecanismos para la generación y exportación de reportes de
verificación de control de kardex, asistencia y vacaciones.
Tabla 1: Objetivos específicos y acciones.
OBJETIVOS ACCIONES
 Realizar entrevistas con el personal

involucrado para obtener datos.
 Analizar los procesos de monitoreo y
control de personal actualmente.
 Averiguar el proceso de almacenamiento
de kardex y las vacaciones.
Analizar el proceso de control de kardex,  Estudiar los sistemas implantados
asistencia y vacaciones y diseñar el actualmente para el control de kardex,
modelado de negocio actual. asistencia y vacaciones.
 Determinar el flujo que siguen los
procesos de control de kardex, asistencia
y vacaciones.
 Validar con los involucrados el modelado
de negocio actual.
 Corregir los errores en el modelado.
10 de 274
OBJETIVOS ACCIONES
 Evaluar las deficiencias existentes en el

proceso actual.
 Elaborar el modelado de negocio
alternativo que se base en el sistema
propuesto.
 Validar con los involucrados la propuesta.
Diseñar el modelo de negocio alternativo
 Corregir los errores.
considerando las ventajas que ofrece
 Obtener el diseño final.
una arquitectura orientada a servicios
 Analizar las metodologías de desarrollo de
para el proceso de control de personal.
software candidatos a ser aplicadas en el
proyecto.
 Seleccionar la metodología apropiada
para el proyecto.
 Planificar el desarrollo del proyecto de
acuerdo a la metodología elegida.
11 de 274
OBJETIVOS ACCIONES
 Analizar los requisitos para el subsistema

de administración de kardex.
 Determinar un lenguaje de programación
adecuado.
 Seleccionar un sistema de gestión de
base de datos.
 Diseñar servicios que permitan administrar
datos de los funcionarios públicos
aplicando SOA.
Desarrollar el subsistema de
administración de kardex basado en  Diseñar la base de datos.
componentes de la Arquitectura  Diseñar los modelos correspondientes
Orientada a Servicios. para el subsistema administración de

kardex.
 Diseñar las interfaces para el subsistema
 Implementar el subsistema de
administración de kardex empleando la
Arquitectura Orientada a Servicios.
 Realizar pruebas al subsistema obtenido.
12 de 274
OBJETIVOS ACCIONES
 Análisis de asignación de horarios.

 Diseñar las interfaces que permiten al
usuario interactuar con el sistema de
manera fácil.
 Diseñar servicios que permitan administrar
datos de ingreso y salida del personal de
la municipalidad aplicando la Arquitectura
Orientada a Servicios.
 Diseñar la base de datos para el
subsistema de control de asistencia
Diseñar e implementar el subsistema de integrado con el subsistema de kardex.
control de asistencia, con el módulo de  Diseñar los modelos correspondientes
asignación de horarios de ingreso y para el subsistema de control de
salidas del personal integrado con el asistencia.
subsistema de administración de kardex.  Implementar los módulos para el sistema
de control de asistencia aplicando la
 Integrar el módulo de ingreso y salidas
con el subsistema de kardex empleando la
 Realizar pruebas a los módulos
integrados.
13 de 274
OBJETIVOS ACCIONES
 Análisis del sistema de vacaciones.

 Diseñar servicios que permitan realizar el
control de vacaciones del personal
aplicando la Arquitectura Orientada a
Servicios.
 Diseñar la base de datos para el
subsistema de vacaciones integrado con
el subsistema de control de asistencia.
 Diseñar los modelos correspondientes
Desarrollar el subsistema de vacaciones para el subsistema de vacaciones.
integrado con el subsistema de control  Diseñar las interfaces del subsistema de
de asistencia. vacaciones.
 Realizar actividades de programación para
implementar las funcionalidades del
subsistema aplicando la Arquitectura
Orientada a Servicios.
 Integrar el subsistema de vacaciones al
módulo de asignación de horarios
empleando la Arquitectura Orientada a
Servicios.
 Realizar las pruebas al sistema.
14 de 274
OBJETIVOS ACCIONES
 Seleccionar el tipo de dispositivo

biométrico.
 Diseñar el módulo que permitirá integrar el
Integrar el sistema basado en
dispositivo biométrico con el sistema.
Arquitectura Orientada a Servicios con
dispositivo de control biométrico.
implementar las funcionalidades de la
interconexión.
 Integrar el módulo de conexión con el
sistema de control de kardex, asistencia y
vacaciones.
 Analizar el tipo de exportación y

generación de datos que se requieren
Implementar mecanismos para la
para la verificación de kardex, control de
generación y exportación de reportes de
asistencia y vacaciones.
verificación de control de kardex,
asistencia y vacaciones.
implementar las funcionalidades de la
exportación y generación de reportes.
 Realizar un análisis de los tipos de

pruebas que se van a realizar.
Realizar pruebas de verificación de  Identificar las pruebas adecuadas para el
funcionamiento al sistema completo. sistema.
 Diseñar escenarios de pruebas.
 Ejecutar las pruebas al sistema.
Fuente: Elaboración propia.
15 de 274
1.5. JUSTIFICACIÓN.
Esta sección describe las diferentes justificaciones del proyecto de grado.
1.5.1. Justificación Técnica.
El beneficio que se obtendrá mediante el desarrollo del sistema de control de

personal aplicando la Arquitectura Orientada a Servicios e integrado con dispositivo
biométrico será que este contará con funcionalidades que le permitirán interactuar
con otros servicios desarrollados en diferentes plataformas para las diferentes
comunas y con el sistema de memorándums, sueldos y salarios que será
desarrollado, permitiendo añadir nuevas funcionalidades futuras sin crearlas,
permitirá realizar tareas de forma rápida, sin duplicación de datos, facilitando las
tareas correspondientes al procesamiento de horarios de manera confiable y segura,
por otro lado la mantenibilidad del código es un proceso más sencillo, ya que se tiene
reusabilidad y organización del mismo.
1.5.2. Justificación Económica.
El sistema de control de personal aplicando la Arquitectura Orientada a Servicios,

beneficiará al G.M.A.C. permitiendo garantizar el almacenamiento de la información
del personal de forma segura, ayudará a controlar el horario dentro del trabajo, para
llevar a cabo los descuentos al personal por días no trabajados y retrasos, además
reducirá el costo de la inversión realizada en material de escritorio, lo cual justifica los
gastos invertidos en el desarrollo del presente proyecto.
1.5.3. Justificación Social.
El sistema de control de personal integrado con dispositivo biométrico permitirá

brindar seguridad a la institución controlando que los funcionarios públicos se
encuentren en su puesto de trabajo cumpliendo con la asistencia y los horarios
establecidos, reducirá el tiempo de proceso en el registro de los datos personales,
generará reportes clasificados de vacaciones según establece el Reglamento Interno
de Personal, otorgará la facilidad para que el personal pueda obtener información
16 de 274
referente al detalle de asistencia que le corresponde en el momento que la requiera,
además de incentivar y motivar al personal a cumplir regularmente y con
responsabilidad, su ingreso a las instalaciones del G.M.A.C.
1.6. ALCANCE.
Esta sección describe los diferentes alcances del tema.
1.6.1. Alcance Temático.
El área en la que se ubica el presente trabajo es el área de Ingeniería de Software,

Análisis y Diseño de Sistemas, Arquitectura Orientada a Servicios, Gestión de Bases
de Datos y Seguridad de Sistemas.
1.6.2. Alcance Institucional.
El presente proyecto tiene como propósito, desarrollar un sistema que permita lograr
la operatividad del control de personal entendiéndose que se tomarán en cuenta los
procesos de control de administración kardex, asistencia y vacaciones, los cuales se
rigen por el reglamento interno de personal y la Ley General del Trabajo.
1.6.3. Alcance Temporal.
Este proyecto será realizado a lo largo de la presente gestión (2014). Se estima que
el sistema estará vigente, hasta la modificación del reglamento interno de personal
dentro de la institución.
1.6.4. Alcance Geográfico.
El Sistema será implementado para el G.M.A.C. ubicado en el departamento de

Cochabamba, provincia Cercado ubicado en la plaza 14 de septiembre.
17 de 274
1.7. HIPÓTESIS.
El Sistema de Control de Personal aplicando la Arquitectura Orientada a Servicios e

integrado al dispositivo biométrico permitirá reducir el tiempo invertido en el proceso
de control de asistencia e identificación de los funcionarios públicos, disminuir los
errores en la elaboración de los reportes respectivos y obtener reportes clasificados
para información de vacaciones.
1.7.1. Análisis de Variables.
Variable independiente.
 Sistema de Control de Personal aplicando la Arquitectura Orientada a

Servicios e integrado al dispositivo biométrico.
Variables dependientes.
 Tiempo invertido en el proceso de control de asistencia e identificación de

los funcionarios públicos.
 Errores en la elaboración de los reportes respectivos.
 Reportes clasificados para información de vacaciones.
1.7.2. Definición Conceptual.
Variable independiente.
 Sistema de Control de Personal aplicando la Arquitectura Orientada a

El sistema permitirá optimizar manejo de la información del personal para

lograr mejorar el seguimiento, teniendo la información oportunamente cuando
se la requiera.
18 de 274
Variables dependientes.
 Tiempo invertido en el proceso de control de asistencia e identificación de

los funcionarios públicos.
El procedimiento de gestión realizado mediante procedimientos manuales en

la administración de personal es agilizado, ya que se debe dar cumplimiento a
plazos establecidos por el reglamento interno de personal, pero no siempre se
puede contar con información actualizada, debido a que el personal designado
a procesar las planillas, no suele disponer de tiempo suficiente para cumplir
con los diferentes procesos. Por lo tanto, con la propuesta realizada se estima
que se obtendrá una notable reducción en el tiempo invertido en el proceso de
gestión de control de personal.
 Errores en la elaboración de los reportes respectivos.
El sistema no genera los reportes necesarios para el control de personal, Para

lo cual la propuesta realizada presenta mayor consistencia en el
procesamiento de la información referente a la gestión de personal, lo cual
permite reducir los errores en la emisión de reportes.
 Reportes clasificados para información de vacaciones.
El sistema no genera los reportes clasificados necesarios para el proceso de

vacaciones, la integración con el subsistema de control de asistencia permitirá
generar la información para los diferentes funcionarios públicos respecto al
control de vacaciones.
19 de 274
1.7.3. Operativización de variables.
Tabla 2: Operativización de variables.
VARIABLE DIMENSIÓN INDICADOR
Variable independiente
Sistema
aplicando la
Sistema de Control de Personal
El desarrollo de la aplicación está Arquitectura
aplicando la Arquitectura Orientada a
aplicado en la Arquitectura Orientada a
Servicios e integrado al dispositivo
Orientada a Servicios. Servicios
biométrico.
desarrollado
y probado.
Variables dependientes
Tiempo invertido en el proceso de La cantidad de tiempo para dar

control de asistencia e identificación de cumplimiento al proceso de Tiempo.
los funcionarios públicos. control de personal.
La reducción de errores en la
Errores en la elaboración de los emisión de reportes del sistema

reportes respectivos. para control de personal, con Numero de
información de mayor errores.
consistencia, que la utilizada
actualmente.
Reportes clasificados para información

Registro de datos de vacaciones. Reportes.
de vacaciones.
20 de 274
1.8. MATRIZ DE CONSISTENCIA.
Figura 1: Matriz de consistencia.
PROBLEMA OBJETIVOS HIPÓTESIS
SISTEMA DE CONTROL DE PERSONAL APLICANDO LA ARQUITECTURA

ORIENTADA A SERVICIOS INTEGRADO CON DISPOSITIVO BIOMÉTRICO, CASO
DE ESTUDIO: GOBIERNO AUTÓNOMO MUNICIPAL DE COCHABAMBA
Los ineficientes procedimien- Desarrollar un sistema

tos manuales, limitaciones de control de personal
El Sistema de Control de Per-
técnicas y funcionamiento aplicando la Arquitec-
sonal aplicando la Arquitectu-
aislado de los sistemas exis- tura Orientada a Ser-
ra Orientada a Servicios e
tentes aplicados en el proce- vicios integrado con
integrado al dispositivo biomé-
so de control de personal del dispositivo biométrico.
trico.
Gobierno Municipal Autóno-
mo de Cochabamba.
PARA
PROVOCA PERMITIRÁ
Retardo en el procesamiento
de la información, posibilidad Reducir el tiempo invertido en
Obtener información
de cometer errores en el pro- el proceso de control de asis-
de manera rápida y
ceso de transcripción a plani- tencia e identificación de los
registro de datos
llas oficiales, molestia por funcionarios públicos, disminuir
coherentes con el
parte del personal, tareas los errores en la elaboración de
reglamento interno de
repetitivas y duplicadas e los reportes respectivos y ob-
personal y la Ley del
incumplimiento del reglamen- tener reportes clasificados para
Trabajo.
to interno de personal y de la información de vacaciones.
Ley General del Trabajo.
21 de 274
2.1. MÉTODOS Y TÉCNICAS DE RECOLECCIÓN DE
INFORMACIÓN.
La recolección de datos para la realización de un proyecto de desarrollo de software,

está relacionada con el uso de técnicas y herramientas para la recolección de la
información. La entrevista, el cuestionario y la observación se constituyen en algunas
de estas técnicas, las mismas que se aplican con el propósito de buscar información
y recopilar datos que serán de gran importancia para el desarrollo de una
investigación.
2.1.1. Métodos interactivos.
2.1.1.1. Entrevistas.
Antes de realizar una entrevista, el entrevistador debe entrevistarse a sí mismo.

Necesita conocer sus prejuicios y cómo afectarán éstos sus percepciones. Su
educación, intelecto, formación, emociones y marco ético actúan como filtros
poderosos de lo que va a oír en sus entrevistas (E. Kendall & E. Kendall, 2005).
El entrevistador debe pensar en detalle las entrevistas que va a realizar antes de

hacerlas. El mismo tendrá que visualizar por qué las va a hacer, qué va a preguntar y
qué es lo que a su juicio hará que esta entrevista tenga éxito. Asimismo, debe pensar
cómo logrará que la entrevista sea satisfactoria para el individuo al que entreviste.
Una entrevista para recabar información es una conversación dirigida con un

propósito específico que utiliza un formato de preguntas y respuestas. En la
entrevista la persona que la realizará, necesita obtener la opinión de los
entrevistados y su parecer acerca del estado actual del sistema y las metas
organizacionales.
Ante todo, el entrevistador debe buscar las opiniones de la persona que entreviste.
Las opiniones podrían ser más importantes y reveladoras que los hechos. Por
ejemplo, podemos imaginar que se le pregunta a la dueña de una tienda tradicional,
quien recientemente estableció una tienda en línea, cuántos reembolsos de clientes
22 de 274
procesa comúnmente mediante transacciones en la Web cada semana. Ella
responde: "Entre 20 y 25 por semana". Cuando usted revisa las transacciones y
descubre que el promedio es de tan sólo 10.5 por semana, podría llegar a la
conclusión de que la propietaria está exagerando los hechos y el problema (E.
Kendall & E. Kendall, 2005).
En cambio, imagine que se le pregunta a la propietaria cuáles son sus principales

preocupaciones y que ella responde: "En mi opinión, son demasiado altas las
devoluciones de productos comprados a través de la Web". Al buscar opiniones más
que hechos, usted descubre un problema clave que la propietaria desea solucionar
(E. Kendall & E. Kendall, 2005).
Además de las opiniones, el entrevistador debe tratar de captar los sentimientos de

los entrevistados. Hay que recordar que éstos conocen la organización mejor que la
persona que realizara la entrevista.
Las metas son información importante que se puede recabar de las entrevistas. Los
hechos que obtenga de los datos concretos y reales podrían explicar el desempeño
pasado, pero las metas reflejan el futuro de la organización. El entrevistador debe
tratar de averiguar lo más que pueda acerca de las metas de la organización por
medio de las entrevistas. Éste quizá sea el único método de recopilación de datos
efectivo para determinar las metas de la organización (E. Kendall & E. Kendall,
2005).
Pasos para preparar una entrevista.
Estos pasos incluyen un rango de actividades que van desde recopilar antecedentes
básicos hasta decidir a quién realizar la entrevista.
Paso 1. Leer los antecedentes.
Leer y entender tanto como sea posible los antecedentes de los entrevistados y su
organización. Con frecuencia este material puede ser obtenido del sitio Web
23 de 274
corporativo, de un informe anual actual, de un boletín corporativo o de cualquier
publicación que explique el estado de la organización.
El entrevistador debe prestar especial atención al lenguaje que utilicen los miembros
de la organización para describirse a sí mismos y a su organización. El propósito es
crear un vocabulario común que en un futuro le permita expresar preguntas de la
entrevista de una manera comprensible para su entrevistado. Otra ventaja de
investigar su organización es maximizar el tiempo que invierta en las entrevistas; sin
esta preparación podría perder tiempo haciendo preguntas generales sobre los
antecedentes.
Paso 2. Establecer los objetivos de la entrevista.
El entrevistador debe utilizar los antecedentes que haya recopilado así como su
propia experiencia para establecer los objetivos de la entrevista. Debe haber de
cuatro a seis áreas clave referentes al procesamiento de la información y el
comportamiento relacionado con la toma de decisiones acerca de las cuales tendrá
usted que hacer preguntas. Estas áreas incluyen fuentes de información, formatos de
información, frecuencia de la toma de decisiones, cualidades de la información y
estilo de la toma de decisiones.
Paso 3. Decidir a quién entrevistar.
Cuando el entrevistador decida a quién entrevistar, debe incluir a gente clave de

todos los niveles que vayan a ser afectadas por el sistema de alguna manera. Este
debe esforzarse por conseguir el equilibrio de tal manera que atienda las
necesidades de tantos usuarios como sea posible. Su persona de contacto en la
organización también tendrá algunas ideas sobre quién deba ser entrevistado.
Paso 4. Preparar al entrevistado.
El entrevistador debe preparar a la persona que va a ser entrevistada hablándole por

anticipado o enviándole un mensaje de correo electrónico y dándole tiempo para
pensar en la entrevista. Si va a realizar una entrevista a profundidad, se puede enviar
24 de 274
las preguntas por correo electrónico con anticipación para darle tiempo al
entrevistado a que piense sus respuestas. Sin embargo, debido a que con la
entrevista se pretende satisfacer muchos objetivos (incluyendo la creación de
confianza y la observación del lugar de trabajo), normalmente ésta se debe realizar
en persona y no por correo electrónico. Las entrevistas se deben llevar a cabo en 45
minutos o una hora a lo mucho. Si las entrevistas duran más de una hora, es
probable que los entrevistados se enfaden, aunque quizá oculten su disgusto.
Paso 5. Decidir el tipo de preguntas y la estructura.
El entrevistador deberá escribir preguntas que abarquen las áreas clave de la toma
de decisiones que haya descubierto al determinar los objetivos de la entrevista. Los
dos tipos básicos de preguntas son las abiertas y las cerradas. Cada tipo de
pregunta puede lograr resultados un poco diferentes a los de la otra, y cada una tiene
ventajas y desventajas.
Es posible estructurar su entrevista de tres modos distintos: una estructura de

pirámide, una estructura de embudo o una estructura de diamante. Cada uno es
apropiado bajo condiciones distintas y tienen funciones diferentes.
Preguntas abiertas.
Las preguntas abiertas describen que las opciones del entrevistado para responder
están abiertas. La respuesta puede ser de dos palabras o dos párrafos.
Las ventajas de utilizar las preguntas abiertas incluyen las siguientes:
 Hacen que el entrevistado se sienta a gusto.

 Permiten al entrevistador entender el vocabulario del entrevistado, el cual
refleja su educación, valores, actitudes y creencias.
 Proporcionan gran cantidad de detalles.
 Revelan nuevas líneas de preguntas que pudieron haber pasado
desapercibidas.
 Hacen más interesante la entrevista para el entrevistado.
25 de 274
 Permiten más espontaneidad.
 Facilitan la forma de expresarse al entrevistador.
 Son un buen recurso si el entrevistador no está preparado para la entrevista.
Las preguntas abiertas tienen muchas ventajas, sin embargo, también tienen muchas
desventajas:
 Podrían dar como resultado muchos detalles irrelevantes.

 Posible pérdida del control de la entrevista.
 Permiten respuestas que podrían tomar más tiempo del debido para la
cantidad útil de información obtenida.
 Dan la impresión de que el entrevistador es inexperto.
 Podrían dar la impresión de que el entrevistador "anda de pesca" sin un
objetivo real en la entrevista.
Se debe considerar con cuidado las implicaciones de utilizar las preguntas abiertas
para entrevistar.
Preguntas cerradas.
Las respuestas posibles se cierran al entrevistado, debido a que sólo puede

contestar con un número finito como "Ninguno", "Uno" o "Quince".
Un tipo especial de pregunta cerrada es la pregunta bipolar. Este tipo de pregunta

limita aún más las opciones del entrevistado pues sólo le permite una opción en cada
polo, como sí o no, verdadero o falso, de acuerdo o desacuerdo (E. Kendall & E.
Kendall, 2005).
Las ventajas de utilizar preguntas cerradas de cualquiera de los dos tipos incluyen lo
siguiente:
 Ahorrar tiempo.
 Comparar las entrevistas fácilmente.
 Ir al grano.
26 de 274
 Mantener el control durante la entrevista.
 Cubrir terreno rápidamente.
Sin embargo, las desventajas de utilizar preguntas cerradas son considerables.

Dichas desventajas incluyen lo siguiente:
 Aburren al entrevistado.
 No permiten obtener gran cantidad de detalles.
 Olvidar las ideas principales por la razón anterior.
 No ayudan a forjar una relación cercana entre el entrevistador y el
entrevistado.
Es así, que el entrevistador, debe pensar cuidadosamente los tipos de pregunta que
utilizará.
2.1.1.2. Cuestionarios.
Es una técnica de recopilación de información que permite estudiar las actitudes,

creencias, comportamiento y características de muchas personas importantes en la
organización que podrían resultar afectadas por los sistemas actuales y los
propuestos. Las actitudes consisten en lo que las personas de la organización dicen
que quieren (en un nuevo sistema, por ejemplo); las creencias son lo que las
personas realmente piensan que es verdad; el comportamiento es lo que los
miembros de la organización hacen, y las características son propiedades de las
personas o cosas (E. Kendall & E. Kendall, 2005).
Es posible cuantificar las respuestas conseguidas a través de cuestionarios (también

conocidos como encuestas) que usan preguntas cerradas.
Las respuestas a cuestionarios que utilizan preguntas abiertas se analizan e

interpretan de otras maneras. La redacción que utilice el analista de sistemas influye
en las respuestas a preguntas sobre actitudes y creencias (E. Kendall & E. Kendall,
2005).
27 de 274
Planeación de cuestionarios.
A primera vista los cuestionarios podrían parecer una manera rápida de recopilar
grandes cantidades de datos sobre la opinión que los usuarios tienen del sistema
actual, sobre los problemas que experimentan con su trabajo y sobre lo que la gente
espera de un sistema nuevo o uno modificado. Aunque es cierto que se puede
recopilar mucha información a través de los cuestionarios sin invertir tiempo en las
entrevistas cara a cara, el desarrollo de un cuestionario útil implica una considerable
cantidad de tiempo de planeación (E. Kendall & E. Kendall, 2005).
A continuación se describen algunas directrices que pueden servir para decidir si es

apropiado el uso de cuestionarios. Se debe considerar el uso de cuestionarios si:
 Las personas que necesita encuestar se encuentran en ubicaciones dispersas

(diferentes instalaciones de la misma corporación).
 Una gran cantidad de personas está involucrada en el proyecto de sistemas, y
es importante saber qué proporción de un grupo dado (por ejemplo, los
directivos) aprueba o desaprueba una característica específica del sistema
propuesto.
 Está haciendo un estudio preliminar y desea medir la opinión general antes de
que se determine el rumbo que tomará el proyecto de sistemas.
 Desea tener la certeza de que en las entrevistas de seguimiento se identificará
y abordará cualquier problema relacionado con el sistema actual.
Una vez que se ha determinado que se tiene buenos motivos para usar un
cuestionario y que se haya precisado los objetivos que se cumplirán por medio de
éste, se puede proceder a elaborar las preguntas.
Redacción de preguntas.
Los tipos básicos de preguntas que se utilizan en los cuestionarios son las abiertas y
las cerradas.
28 de 274
Preguntas abiertas.
Las preguntas abiertas son aquellas que dejan abiertas al encuestado todas las
posibles opciones de respuesta.
Cuando redacte preguntas abiertas para un cuestionario, el encuestador debe

anticipar qué tipo de respuesta obtendrá. Por ejemplo, si se realiza la pregunta
"¿Qué piensa del sistema?", las respuestas podrían ser demasiado amplias para
interpretarlas o compararlas con precisión.
En consecuencia, aun cuando se redacte una pregunta abierta, debe ser

suficientemente específica para guiar al encuestado a responder de una manera
particular (E. Kendall & E. Kendall, 2005).
Preguntas cerradas.
Las preguntas cerradas son aquellas que limitan o cierran las opciones de respuesta
disponibles para el encuestado.
Hay ventajas y desventajas involucradas en la elección de las preguntas abiertas o

cerradas que se usan en los cuestionarios. La Figura 2 resume estos compromisos.
Se observa que las respuestas a las preguntas abiertas pueden ayudar a obtener
una alta comprensión preliminar, así como una alta amplitud y profundidad, sobre un
tema. Aunque la redacción de las preguntas abiertas es sencilla, sus respuestas son
difíciles y su análisis toma mucho tiempo (E. Kendall & E. Kendall, 2005).
Figura 2: Intercambios entre el uso de preguntas abiertas y cerradas.
Fuente: E. Kendall & E. Kendall, 2005.
29 de 274
2.1.2. Métodos no intrusivos.
2.1.2.1. Muestreo.
El muestreo es el proceso consistente en seleccionar sistemáticamente elementos

representativos de una población. Cuando dichos elementos se examinan con
cuidado, se da por hecho que el análisis revelará información útil de la población en
general (E. Kendall & E. Kendall, 2005).
2.1.2.2. Investigación.
La investigación es la acción de descubrir y analizar los datos. Al investigar las

evidencias en una organización, el analista actúa como Sherlock Holmes, el
legendario detective del 22IB de Baker Street (E. Kendall & E. Kendall, 2005).
Conforme el analista de sistemas se esfuerza por entender la organización y sus

requerimientos de información, es importante que examine los diferentes tipos de
datos reales que ofrecen información no disponible a través de ningún otro método
de recopilación de datos. Los datos reales revelan en dónde está la organización y
hacia dónde creen sus miembros que se dirige (E. Kendall & E. Kendall, 2005).
2.1.2.3. Observación.
La observación del tomador de decisiones y su entorno físico son métodos no

intrusivos importantes para el analista de sistemas. Al observar las actividades del
tomador de decisiones, el analista busca darse una idea de lo que realmente se
hace, no sólo de lo que se documenta o explica. Además, al observar al tomador de
decisiones, el analista trata de ver personalmente las relaciones que existen entre el
tomador de decisiones y los demás miembros de la organización (E. Kendall & E.
Kendall, 2005).
2.2. ARQUITECTURA ORIENTADA A SERVICIOS.
La Arquitectura Orientada a Servicios establece un marco de diseño para la

integración de aplicaciones independientes de manera que desde la red pueda
30 de 274
accederse a sus funcionalidades, las cuales se ofrecen como servicios. La forma
más habitual de implementarla es mediante Servicios Web, una tecnología basada
en estándares e independiente de la plataforma, con la que la arquitectura puede
descomponer aplicaciones en un conjunto de servicios e implementar esta
funcionalidad en forma modular (Corporation, 2006).
La Arquitectura Orientada a Servicios es un enfoque para la definición de la

arquitectura, la vinculación y la integración de los servicios de negocio reutilizables
que tienen límites claros y son independientes con sus propias funcionalidades
(Mabrouk, 2008).
Debido a que una Arquitectura Orientada a Servicios se basa en estándares

reconocidos y apoyados por los principales proveedores de TI, tales como servicios
web, puede crear rápidamente e interconectar sus servicios.
Con una Arquitectura Orientada a Servicios establecido, se trae la infraestructura

interna a un nivel superior, más visible y fácil de administrar. Con los servicios
reutilizables y procesos de alto nivel, el cambio es más fácil que nunca y es más
como el montaje y desmontaje partes (servicios) en nuevos procesos, alineados con
el negocio. Esto no sólo promueve la eficiencia y la reutilización, que proporciona una
gran capacidad para cambiar y alinear las TI con el negocio (Mabrouk, 2008).
2.2.1. Capas de software.
 Aplicaciones básicas.
Sistemas desarrollados bajo cualquier arquitectura o tecnología,

geográficamente dispersos y bajo cualquier figura de propiedad (BearSoft,
2014).
 De exposición de funcionalidades.
Donde las funcionalidades de la capa aplicativa son expuestas en forma de

servicios (generalmente como servicios web) (BearSoft, 2014).
31 de 274
 De integración de servicios.
Facilitan el intercambio de datos entre elementos de la capa aplicativa

orientada a procesos empresariales internos o en colaboración (BearSoft,
2014).
 De composición de procesos.
Que define el proceso en términos del negocio y sus necesidades, y que varía
en función del negocio (BearSoft, 2014).
 De entrega.
Donde los servicios son desplegados a los usuarios finales (BearSoft, 2014).
2.2.2. Principios de La Arquitectura Orientada a Servicios.
La Arquitectura Orientada a Servicios tiene cuatro principios básicos los mismos que
se describen a continuación:
 Límites: los servicios están demarcados por límites específicos y la única

forma de comunicarse con ellos será a través de la tecnología o protocolos
expuestos por ellos.
 Autonomía: cada servicio deberá comportarse de forma autónoma. Por

ejemplo, esto quiere decir que si mi sistema hace uso de un servicio que
consulta una base de datos, mi sistema no tendrá por qué saber ni conocer a
qué tipo de base de datos se está conectando este servicio ni de qué manera
lo hace. Así obtendremos un diseño totalmente desacoplado.
 Contratos: aquí se definen como serán utilizados los servicios y de qué

manera intercambiaran los datos y mensajes.
 Políticas: cada servicio deberá definir las políticas de su uso, como por
ejemplo, que se deberá utilizar el protocolo HTTP o que se requerirá el uso de
transacciones para ser utilizado.
32 de 274
2.2.3. Implementación de la Arquitectura Orientada a Servicios.
La Arquitectura Orientada a Servicios puede ser implementada utilizando un amplio

rango de tecnologías como se muestra en la siguiente, incluyendo RPC, DCOM,
CORBA o Servicios Web.
Figura 3: Tecnologías de implementación de la SOA.
Fuente: Elaboración Propia.
2.2.4. Roles de La Arquitectura Orientada a Servicios.
Hay dos formas de ver la arquitectura de los servicios de Web. La primera es

examinar los roles individuales de cada actor del servicio de Web, en la que se
puede interpretar como una arquitectura orientada a servicios; la segunda es
examinar el servicio Web surgiendo de la pila protocolar o de interoperabilidad.
Hay tres roles mayores dentro de la arquitectura del servicio Web:
 Proveedor de Servicios: Es el proveedor del servicio Web. El proveedor de

servicios lleva a cabo el servicio y lo hace disponible en Internet.
 Solicitante de Servicios: Es cualquier consumidor del servicio Web. El
solicitante utiliza un servicio del Web existente abriendo una conexión de red y
enviando una petición XML.
 Registro de Servicios: Es un directorio lógicamente centralizado de servicios.
El registro proporciona un lugar central dónde los desarrolladores pueden
33 de 274
publicar los nuevos servicios o pueden encontrar existentes. Sirve por
consiguiente como una cámara de prestación centralizada para las compañías
y sus servicios.
Figura 4: Roles en los servicios Web.
Fuente: Internet, 2013; Delgado, González, & Piedrabuena, 2003.
Al asumir los roles de servicios, en la actualidad las aplicaciones Web son basadas
en una arquitectura distribuida, las aplicaciones Web se han movido fuera de la
naturaleza centralizada de datos de aplicaciones típicas del cliente-servidor y han
cuidado más a una arquitectura orientada a servicios.
2.2.5. Tecnologías y estándares de la Arquitectura Orientada a Servicios.
 XML-RPC.
Protocolo simple basado en xml para el intercambio de información entre

sistemas. Los Requests son codificados en xml y enviados vía HTTP POST.
Las respuestas son embebidas en el cuerpo de la respuesta HTTP.
 SOAP.
Protocolo de comunicación basado en xml para intercambio de mensajes entre

sistemas. Especifica un formato para el intercambio de mensajes es
34 de 274
independiente del lenguaje y de la plataforma. Es extensible, es desarrollado
por la W3C.
 WSDL.
Es un formato estándar basado en xml para describir servicios web y mostrar

como acceder a ellos.
 UDDI.
Es un lenguaje estándar basado en xml para describir, publicar y encontrar

servicio web. Es independiente de plataforma y puede comunicarse mediante
SOAP, CORBA y JAVA Rmi.
2.2.6. Facilitadores tecnológicos clave de SOA.
Existen cinco facilitadores tecnológicos principales como se muestra en la Figura 5

que permiten, desde el punto de vista tecnológico, la implantación de SOA. No es
imprescindible el uso de todos los facilitadores, pero cada de ellos es importante para
alcanzar plenamente todos los beneficios esperados.
 La tecnología de Web Services.
Permite encapsular los servicios mediante un estándar ampliamente aceptado

por todos los fabricantes y proveedores. Este estándar proporciona ventajas
claras para proveer y consumir servicios al exterior, pero no es obligatoria su
implementación en entornos cerrados.
 El ESB o Enterprise Service Bus.
Facilita la conexión entre sistemas/servicios heterogéneos, resolviendo

deficiencias de la tecnología de web services como la garantía de entrega,
localización, seguridad, transaccionalidad, etc. Dependiendo de la
heterogeneidad de una instalación, su uso puede ser imprescindible o no ser
requerido.
35 de 274
 BAM o Business Activity Monitoring
Proporciona una monitorización de los procesos (con una visión de negocio)

en tiempo real y con capacidad de actuación.
 El Gobierno de desarrollo
El ESR o Enterprise Service Repositorio, es el catálogo de servicios y

procesos (tanto desde el punto de vista técnico como de negocio) y es
fundamental para la gestión de los servicios y procesos tanto desarrollados
como comprados.
 El Gobierno de ejecución
Es un conjunto de herramientas y utilidades que permiten el gobierno de los

servicios y procesos en ejecución, generando cuadros de mando de niveles de
servicio y aplicando políticas de actuación automáticas. Bajo este facilitador
también se suelen cubrir todos los aspectos de seguridad en SOA.
Figura 5: Facilitadores tecnológicos clave de SOA.
Fuente: Corporation, 2006.
36 de 274
Beneficios de una Arquitectura Orientada a Servicios.
Existen cinco factores importantes que aumentan el interés por la Arquitectura

Orientada a Servicios:
 Ayuda a mejorar la agilidad y flexibilidad de las organizaciones.

 Permite una “personalización masiva” de las tecnologías de la información.
 Permite la simplificación del desarrollo de soluciones mediante la utilización de
estándares de la industria y capacidades comunes de industrialización.
 Permite aislar mejor a los sistemas frente a los cambios generados por otras
partes de la organización (protección de las inversiones realizadas).
 Permite alinear y acercar las áreas de tecnología y negocio.
2.2.7. Servicios Web.
Un servicio es una funcionalidad concreta que puede ser descubierta en la red y que
describe tanto lo que puede hacer como el modo de interactuar con ella (Microsoft
Corporation, 2006).
Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede

corresponder a un proceso de negocio tan sencillo como introducir o extraer un dato
como “Código del Cliente”. Pero también los servicios pueden acoplarse dentro de
una aplicación completa que proporcione servicios de alto nivel, con un grado de
complejidad muy superior, por ejemplo, “introducir datos de un pedido”, un proceso
que, desde que comienza hasta que termina, puede involucrar varias aplicaciones de
negocio (Corporation, 2006).
La adopción de una solución de diseño basada en SOA no exige implantar servicios

Web. No obstante, los servicios Web son la forma más habitual de implementar SOA.
Los servicios Web permiten la intercomunicación entre sistemas de cualquier

plataforma y se utilizan en una gran variedad de escenarios de integración
(Corporation, 2006).
37 de 274
Por ejemplo, una aplicación como Access está formada por un conjunto de
componentes que ofrecen una serie de servicios, como el acceso a datos, la
impresión de informes, el diseño de tablas y otros.
La idea de los servicios es la misma, aunque éstos no tienen por qué estar en el
mismo ordenador que el cliente y además son accedidos a través de un servidor
Web y de un modo independiente de la plataforma, utilizando protocolos estándar
(HTTP, SOAP, WSDL, UDDI) como se muestra en la Figura 6.
Figura 6: Pila de protocolos de los Servicios Web.
Fuente: Corporation, 2006.
2.2.7.1. Pila de interoperabilidad.
La pila todavía está evolucionando, pero actualmente tiene cuatro capas principales
como se aprecia en la Figura 7.
 Transporte de Servicio: Esta capa es responsable para transportar los

mensajes entre las aplicaciones. Actualmente, esta capa incluye el protocolo
de transferencia de hipertexto (HTTP), el protocolo simple de transferencia de
correo (SMTP), el protocolo de transferencia de archivo (FTP) y los más
reciente protocolos, como el protocolo intercambio de bloques extensible
(BEEP).
38 de 274
 Mensajería XML: Esta capa es responsable para codificar los mensajes en un
XML común que da formato para que puedan entenderse mensajes a
cualquier fin. Actualmente, esta capa incluye XML-RPC y SOAP.
 Descripción de Servicio: Esta capa es responsable para describir la interfaz
pública a un servicio Web específico. Actualmente la descripción de servicio
es manejado por el lenguaje WSDL.
 Descubrimiento de servicio: Esta capa es responsable para centralizar los
servicios en un registro común y proporcionando fácil funcionalidad en la
publicación y localización. Actualmente, el descubrimiento de servicio es
manejado por UDDI.
Figura 7: Pila de interoperabilidad de los servicios Web.
Como los servicios Web evolucionan, pueden agregarse capas adicionales y pueden
agregarse tecnologías adicionales a cada capa.
Los servicios Web se basan en un conjunto de estándares de comunicación, como

son XML para la representación de datos, SOAP para el intercambio de datos y el
lenguaje WSDL para describir las funcionalidades de un servicio Web (Microsoft
Corporation, 2006).
39 de 274
Figura 8: Los servicios Web en Funcionamiento.
Fuente: W3C, 2014.
Según el ejemplo de la Figura 8, un usuario, a través de una aplicación, solicita

información sobre un viaje que desea realizar haciendo una petición a una agencia
de viajes que ofrece sus servicios a través de Internet. La agencia de viajes ofrecerá
a su cliente (usuario) la información requerida. Para proporcionar al cliente la
información que necesita, esta agencia de viajes solicita a su vez información a otros
recursos (otros Servicios Web) en relación con el hotel y la compañía aérea. La
agencia de viajes obtendrá información de estos recursos, lo que la convierte a su
vez en cliente de esos otros Servicios Web que le van a proporcionar la información
solicitada sobre el hotel y la línea aérea. Por último, el usuario realizará el pago del
viaje a través de la agencia de viajes que servirá de intermediario entre el usuario y
el servicio Web que gestionará el pago (W3C, 2014).
En todo este proceso intervienen una serie de tecnologías que hacen posible esta
circulación de información. Por un lado, estaría SOAP. Se trata de un protocolo
basado en XML, que permite la interacción entre varios dispositivos y que tiene la
capacidad de transmitir información compleja. Los datos pueden ser transmitidos a
través de HTTP , SMTP , etc. SOAP especifica el formato de los mensajes. El
40 de 274
mensaje SOAP está compuesto como se observa en la Figura 9 por
un envelope (sobre), cuya estructura está formada por los siguientes
elementos: header (cabecera) y body (cuerpo) (W3C, 2014).
Figura 9: Estructura de los mensajes.
Fuente: W3C, 2014.
2.2.7.2. .NET y servicios Web.
El modelo de desarrollo para construir los servicios Web con Microsoft .NET se
describe a continuación.
 La aplicación de .NET.
Se organiza dentro de un contenedor que provee calidades de servicio

necesario a las aplicaciones de empresas como transacciones, seguridad y
servicios de mensajería.
 La capa de negocios.
Es construida usando componentes administrados de .NET. Esta capa realiza

proceso de negocios y lógica de datos. Conecta a bases de datos usando
41 de 274
Active Data Objects (ADO.NET) y los sistemas existentes mediante los
servicios proporcionadas por Microsoft Host Integration Server 2000, como el
COM Transaction Integrator (COM TI). También puede conectar a socios de
negocios que usan las tecnologías de servicios Web (SOAP, UDDI, WSDL).
 Los socios de negocios.
Pueden conectar con la aplicación de .NET a través de las tecnologías de

servicios Web (SOAP, UDDI, WSDL, BizTalk ).
 Clientes tradicionales “densos”, exploradores Web y dispositivos

inalámbricos.
Se conectan a Active Server Pages (ASP.NET) que dan las interfaces del
usuario en HTML, XHTML o WML. Se construyen interfaces del usuario
usando Windows Forms.
2.2.7.3. Creación de un servicio web.
Para crear un servicio puede utilizarse cualquiera de los lenguajes disponibles en la

plataforma .NET.
Una vez creado el servicio, para conseguir que sea accesible por los consumidores,
es necesario describirlo utilizando un lenguaje estándar llamado WSDL. Los clientes
del servicio podrán estar creados en cualquier lenguaje y ejecutarse sobre cualquier
sistema operativo y hardware, lo único necesario es que sean capaces de obtener y
entender la descripción WSDL de un servicio.
Un archivo WSDL es, en realidad, un archivo XML en el que se identifica el servicio y

se indica el esquema para poder utilizarlo, así como el protocolo o protocolos que es
posible utilizar. Una vez dispone de esta información, el cliente puede comunicarse
con el servicio utilizando protocolos como HTTP o SOAP (SOAP añade invocación
de métodos a HTTP, aunque es posible hacerlo con peticiones HTTP-GET y/o HTTP-
POST en lugar de SOAP).
42 de 274
Además de describir un servicio para que pueda ser utilizado por los clientes es
importante publicar el servicio de modo que pueda ser encontrado por clientes que
no conozcan necesariamente el componente que ofrece el servicio, pero que
busquen un servicio de sus características. Esto se logra mediante el estándar UDDI.
Realmente se trata de un servicio, mundial en el que los proveedores de servicios
pueden registrarlos de modo gratuito.
Figura 10: Creación, registro, búsqueda y utilización de un Servicio Web.
Protocolos alternativos.
A continuación se comentan brevemente algunas alternativas a los protocolos

descritos anteriormente:
En el caso de HTTP y SOAP otras opciones (en este caso sustitutivas y/o
complementarias) son:
 Jabber, es un protocolo asíncrono de transporte (más ligero que HTTP).

 EbXML, está pensado para integración de servicios en soluciones B2B
(Business to Business).
43 de 274
 XML-RPC, está basado en HTTP-POST.
En el caso de WSDL otras opciones son:
 RDF (Resource Description Framework), definido por el W3C. Es más potente

pero también más complejo que WSDL.
 DAML (DARPA Agent Markup Language), definido por la agencia de defensa
estadounidense (DARPA). Es también más potente pero más complejo que
WSDL.
En el caso de UDDI existe una propuesta alternativa realizada por Microsoft e IBM,
llamada WS-Inspection Language.
2.2.7.4. Enfoque solicitud de servicio.
El solicitante de servicio es cualquier consumidor de servicios del Web. Un plan de

desarrollo típico para un solicitante de servicio en orden es el que se aprecia en la
Figura 11.
 Debe identificar y descubrir esos servicios que son pertinentes para su

aplicación. Este primer paso por consiguiente normalmente envuelve la
búsqueda del directorio de negocios UDDI para los socios y servicios.
 Una vez identificado el servicio que quiere, el próximo paso es localizar una
descripción del servicio. Si éste es un servicio de SOAP, es probable que
encuentre un documento de WSDL. Si esto es un servicio XML-RPC, es
probable que encuentre algunas instrucciones humano-leíbles para la
integración.
 Debe crear una aplicación del cliente. Por ejemplo, puede crear un XML-RPC
o un cliente SOAP en el lenguaje de su opción. Si el servicio tiene un archivo
de WSDL, también tiene la opción de crear el código del cliente
automáticamente vía una herramienta de invocación WSDL.
 Finalmente, ejecute su aplicación del cliente para invocar el servicio Web
actualmente.
44 de 274
Figura 11: Solicitud de servicio.
2.2.7.5. Enfoque proveedor de servicios.
El proveedor de servicios es cualquier proveedor de uno o más servicios del Web. Un

plan de desarrollo típico para un proveedor de servicios en orden es el que se
muestra en la Figura 12 y se describe en los siguientes párrafos:
 Debe desarrollar la funcionalidad del núcleo de su servicio. Ésta normalmente

es la parte más dura, cuando su aplicación puede conectar a las bases de
datos, elementos EJB o COM+, o aplicaciones de herencia.
 Debe desarrollar una envoltura de servicio a su funcionalidad del núcleo. Esto
podría ser un XML-RPC o una envoltura de servicio SOAP. Éste normalmente
es un paso relativamente simple, como está envolviendo la funcionalidad
existente meramente en una plataforma mayor.
 Luego, debe proporcionar una descripción de servicio. Si está creando una
aplicación de SOAP, debe crear un archivo de WSDL. Si está creando un
servicio XML-RPC, debe considerar la creación de algunas instrucciones
humano-leíbles.
 Necesita desplegar el servicio. Dependiendo de sus necesidades, esto
representa instalarlo y ejecutarlo en un servidor autónomo o integrarlo con un
servidor del Web existente.
45 de 274
 Necesita publicar la existencia y característica técnicas de su nuevo servicio.
Esto normalmente representa los datos de la publicación a un directorio de
UDDI global o quizás un directorio de UDDI privado específico a su compañía.
Figura 12: Proveedor de servicios.
2.2.7.6. Estructura y funcionamiento de la aplicación.
Como se explicó anteriormente, un servicio Web puede ser una aplicación intermedia
que permite que una aplicación cliente del servicio Web acceda a datos de una base
de datos de apoyo. Para realizar esto podemos representar la estructura del servicio
Web y su interacción con el cliente Web mediante las capas siguientes:
 Capa de datos: Es la primera de las capas del servicio Web y contiene los
datos a los que debe acceder el servicio Web.
 Capa de acceso a datos: Está situada por encima de la capa de datos y
contiene la lógica de negocio o el código que permite que la aplicación cliente
del servicio Web acceda a los datos de la capa inferior. Además de almacenar
datos, esta capa se usa para proteger los datos de la capa de datos.
 Capa de negocio: La tercera capa del servicio Web contiene el código
necesario para implementar el servicio Web. La capa de negocio se divide a
46 de 274
su vez en las capas de lógica de negocio y de fachada de negocio. La capa de
lógica de negocio contiene todos los servicios que proporciona el servicio Web
y la capa de fachada actúa como la interfaz del servicio Web.
 Capa de escucha: La capa más cercana al cliente del servicio Web se
emplea para comunicar con el servicio Web. Cuando un cliente de servicio
Web quiere acceder a un método Web presente en un servicio Web, el cliente
envía una petición. Esta petición la recoge la capa de escucha, que la
interpreta. Cuando se procesa la petición y el servicio Web devuelve la
respuesta como un mensaje XML, la capa de escucha es quien se la reenvía
al cliente del servicio Web.
Figura 13: Estructura de un servicio Web.
2.2.7.7. Funcionamiento de un servicio web.
El funcionamiento de un servicio Web implica el envío de una petición por parte del
cliente para obtener un servicio. Esta petición es un mensaje XML que se envía con
un protocolo como HTTP.
47 de 274
Esta situación es parecida a la sentencia de llamada a un método que empleamos
para llamar a un método concreto.
La petición del servicio se le pasa a la capa de escucha, que la reenvía al proveedor

del servicio Web. Entonces, el proveedor de servicio Web procesa la petición.
El procesamiento de la petición incluye la capa de acceso para obtener los datos

pedidos por la aplicación cliente. Estos datos se le pasan entonces a la capa de
escucha, que a su vez se los reenvía a la aplicación cliente. La figura siguiente
muestra el funcionamiento de un servicio Web.
Figura 14: Funcionamiento de un servicio Web.
Cuando una aplicación cliente envía la petición de un servicio, es posible que se le

tenga que pasar argumentos.
Para enviar argumentos a través de una red, éstos se empaquetan como un mensaje
SOAP y se le pasan al método Web con un protocolo de red.
48 de 274
Posteriormente, el servicio Web decodifica el mensaje SOAP para obtener los
argumentos que le hemos pasado al método Web, se ejecuta el método y se le pasa
el valor de vuelta a la aplicación Web cliente.
Ventajas de los servicios web.
Entre las ventajas más importantes que ofrecen los servicios web se pueden citar:
 Ofrecen una “tecnología distribuida de componentes” optimizada.

 Evitan los problemas inherentes a la existencia de firewalls, ya que SOAP
utiliza HTTP como protocolo de comunicación.
 Permiten una invocación sencilla de métodos, mediante SOAP.
 Los clientes o “consumidores de servicios” pueden estar en cualquier
plataforma (basta con que soporten XML/SOAP, incluso puede sustituirse
SOAP por HTTP).
 Permiten centralizar los datos, independientemente de si los servicios web
están distribuidos o no.
2.3. TECNOLOGÍA BIOMÉTRICA.
La biometría es una ciencia que analiza las distancias y posiciones entre las partes
del cuerpo para poder identificar o clasificar a las personas (Serratosa).
El reconocimiento biométrico.
El reconocimiento biométrico se refiere al uso de diferentes características

anatómicas (como huellas dactilares, cara o iris) y de comportamiento (como habla,
firma o teclear). Estas características se denominan identificadores biométricos o
rasgos biométricos y sirven para reconocer automáticamente a los individuos
(Serratosa).
2.3.1. Sistemas biométricos.
En función del contexto de la aplicación biométrica, podemos diferenciar dos tipos de

sistemas, los sistemas de verificación y los sistemas de identificación (Serratosa).
49 de 274
Un sistema biométrico debe tener una precisión y velocidad aceptable con un
número de recursos razonable. Además, no puede ser nocivo para los usuarios,
debe ser aceptado por los usuarios potenciales y ser lo suficientemente robusto ante
los métodos fraudulentos (Serratosa).
Algunas características biométricas que se utilizan actualmente son: voz, huellas

dactilares, cara, iris, retina, venas de la mano, forma de la mano, forma de la oreja,
forma de andar, forma de escribir en un teclado, firma, ADN y olor. Partiendo de
estas características se han desarrollado dispositivos que han tenido mayor o menor
éxito en el mercado. En la actualidad, los sistemas comerciales más usados son:
Reconocimiento facial. Estos sistemas extraen los rasgos faciales de los usuarios
para su identificación. La fuente para realizar la identificación puede ser tanto
imágenes fotográficas como de vídeo. La identificación se puede hacer en 2D, 3D o
una combinación de ambas. El objetivo de un sistema de reconocimiento facial es,
generalmente, el siguiente: dada una imagen de una cara desconocida, o imagen de
test, encontrar una imagen de la misma cara en un conjunto de imágenes conocidas,
o imágenes de entrenamiento. La gran dificultad añadida es la de conseguir que este
proceso se pueda realizar en tiempo real.
Lector de impresión digital. Esta tecnología se basa en identificar al individuo por

medio de su huella dactilar. Aunque puede utilizarse cualquier dedo de la mano, por
una cuestión de dimensión y comodidad, los dedos más utilizados son el índice y el
corazón.
Su funcionamiento se basa en tomar una imagen de la huella y por medio de

algoritmos reducir dicha imagen a una representación matemática de la huella
(“plantilla”) y compa. Esta plantilla patrón se acumula en la memoria interna del
equipo (junto con un número de identificación o PIN si se trata de un verificador, a fin
de tener asociada la huella al individuo). Luego, cada vez que la persona necesite
identificarse, ya sea para registrar su horario de ingreso o regreso al trabajo o activar
una puerta o barrera, debe digitar su PIN (en el caso que sea un verificador) y a
continuación colocar su dedo (el mismo que registró originalmente) en el lector.
50 de 274
Reconocimiento de manos. El reconocimiento de la mano se puede hacer en dos y
tres dimensiones. Los sistemas de dos dimensiones buscan en la palma de la mano
patrones en las líneas, estos patrones son casi tan distintivos como las huellas
digitales. El sistema toma entonces las características de la palma, los compara
contra el modelo de referencia, y procede en consecuencia.
Los lectores de tres dimensiones, sin embargo funcionan de forma distinta. Estos
miden las dimensiones de la mano (largo de los dedos, altura de la mano, etc.).
Aunque no es la más segura de las técnicas biométricas, el uso de la palma de la
mano como medida de autenticación ha resultado ser una solución ideal para
aplicaciones de seguridad media y donde la conveniencia es considerada una opción
mucho más importante que la seguridad o la precisión.
Sistema de autentificación biométrica de las venas. Es sistema que captura la

distribución de las venas de la palma de la mano o de los dedos. Está siendo muy
utilizado en la actualidad debido a su fácil implementación y gran aceptabilidad por
parte de los usuarios ya que muchos de ellos no requieren de contacto físico.
Sistema de identificación mediante el iris. La identificación basada en el

reconocimiento de iris es más moderna que la basada en patrones retinales; desde
hace unos años el iris humano se viene utilizando para la autenticación de usuarios.
Se captura una imagen del iris en blanco y negro, en un entorno correctamente

iluminado, usando una cámara de alta resolución. Generalmente esto se hace
mirando a través de la lente de una cámara fija, la persona simplemente se coloca
frente a la cámara y el sistema automáticamente localiza los ojos, los enfoca y
captura la imagen del iris, ésta imagen se somete a deformaciones pupilares (el
tamaño de la pupila varía enormemente en función de factores externos, como la luz)
y de ella se extraen patrones, que a su vez son sometidos a transformaciones
matemáticas hasta obtener una cantidad de datos suficiente para los propósitos de
autenticación.
51 de 274
Sistema de reconocimiento mediante de la vasculatura retinal. La vasculatura
retinal (forma de los vasos sanguíneos de la retina humana) es un elemento
característico de cada individuo, tan distinto como una impresión digital y
aparentemente más fácil de ser leído, por lo que numerosos estudios en el campo de
la autenticación de usuarios se basan en el reconocimiento de esta vasculatura.
En los sistemas de autenticación basados en patrones retinales el usuario a

identificar ha de mirar a través de unos binoculares, ajustar la distancia ínter-ocular y
el movimiento de la cabeza, mirar a un punto determinado y por último pulsar un
botón para indicar al dispositivo que se encuentra listo para el análisis.
En ese momento sé escanea la retina con una radiación infrarroja de baja intensidad
en forma de espiral, detectando los nodos y ramas del área retinal para compararlos
con los almacenados en una base de datos; si la muestra coincide con la
almacenada para el usuario que el individuo dice ser, se permite el acceso.
Sistema de reconocimiento de firmas. La firma es un método de verificación de

identidad de uso común. Diariamente las personas utilizan su firma para validar
cheques y documentos importantes. Como la firma es una habilidad adquirida, se le
considera un rasgo de comportamiento. Además es muy complejo reproducir la
habilidad humana de identificar si una firma es o no auténtica.
En biometría, el uso de la firma para verificación de identidad se hace de una manera

diferente a la tradicional. Dependiendo del sistema, tanto la superficie donde se firma
como el bolígrafo utilizado pueden contener varios sensores. Estos sensores miden
características mucho más allá que simplemente la forma o apariencia de la firma: la
presión que se aplica sobre la superficie, el ángulo al cual se sujeta el bolígrafo y
hasta la velocidad y el ritmo de cómo la persona ejecuta su firma son características
capturadas por el sistema.
Sistema de Reconocimiento de voz: La voz es otra característica que las personas

utilizan comúnmente para identificar a los demás. Es posible detectar patrones en el
espectro de la frecuencia de voz de una persona que son casi tan distintivos como
52 de 274
las huellas dactilares. Tan solo basta recordar las veces en que se reconoce a
alguien conocido por teléfono para comprender la riqueza de esta característica
como método de reconocimiento.
Los sistemas de verificación mediante la voz “escuchan” mucho más allá del modo
de hablar y el tono de voz. Mediante el análisis de los sonidos que se emiten, los
tonos bajos y agudos, vibración de la laringe, tonos nasales y de la garganta,
también crean modelos de la anatomía de la tráquea, cuerdas vocales y cavidades.
Muchos de estos sistemas operan independientemente del idioma o el acento de la
persona
Importancia de la identificación personal.
El problema de resolver la identidad de una persona se puede clasificar

fundamentalmente en dos tipos distintos de planteamientos: reconocimiento (más
popularmente conocido como identificación) y verificación.
El reconocimiento se centra en determinar la identidad del sujeto dentro de un

conjunto ya conocido de identidades. La verificación se encamina a confirmar o
denegar la identidad aducida por una persona. En muchas situaciones de nuestra
vida cotidiana nos vemos requeridos a probar nuestra identidad, como por ejemplo
cuando realizamos una compra con una tarjeta de crédito.
Una verificación certera de la identidad de una persona podría disuadir la

delincuencia y el fraude, dinamizar las transacciones comerciales y salvaguardar los
recursos críticos.
Ventajas de la biometría.
Son claras las ventajas que se obtienen al utilizar sistemas biométricos.
Es fácil de usar. La utilización de sistemas biométricos libera al usuario del uso de

elementos externos auxiliares. De forma resumida:
 El usuario no tiene nada que recordar,
53 de 274
 Nada que cambiar,
 Nada que perder.
Proporciona un nivel más alto de seguridad ya que los parámetros utilizados son
unívoca “firma” de una característica humana que no puede ser fácilmente adivinada
o descifrada.
La biométrica explota el hecho de que ciertas características biológicas son

singulares e inalterables y son además, imposibles de perder, transferir u olvidar.
Esto las hace más confiables, amigables y seguras que las contraseñas.
Por razones de automatización. En el pasado el procesamiento de biométrico era

hecho manualmente por gente que física y mentalmente comparaba huellas
dactilares contra tarjetas, rostros contra fotos de pasaportes y voces contra cintas
grabadas nada que recordar. Hoy en día, dispositivos tales como escáneres,
videocámaras, y micrófonos pueden, electrónicamente, capturar y entregar estas
mismas características biométricas para automatizar procesos y comparaciones.
Cada tecnología biométrica (huella dactilar, rostro, voz, etc.) tiene sus propias
características, variedades y certezas.
Los niveles de precisión biométricos pueden variar pero son siempre más confiables
que el 100% de falsas aceptaciones experimentadas con las contraseñas prestadas
o robadas.
2.3.2. Tipos de dispositivos biométricos en el mercado.
 Escáner híbrido sin contacto para huellas y venas de los dedos.
Este sistema escáner sin contacto HS100-10 Contactless Hybrid Finger

Scanner emplea la autenticación de la huella digital y también de las venas de
los dedos, pero no requiere ningún contacto físico para obtener los datos que
se necesitan para autentificar la identidad de un individuo mediante ambas
modalidades biométricas (Travieso González, del Pozo Baños, & Ticay Rivas,
2011).
54 de 274
 Control de Acceso y Asistencia.
Es un sistema integrado que cuenta con los sensores y algoritmos para

realizar reconocimiento facial en 3D.
Además de las tareas estrictamente biométricas permite llevar un registro

temporal de acceso, permite almacenar información de hasta 1400 usuarios e
incluso autenticarse en condiciones lumínicas adversas. La información puede
ser descargada vía pendrives y/o TCP/IP (Travieso González, del Pozo Baños,
& Ticay Rivas, 2011).
 Sistema biométrico de reconocimiento del iris.
Este sistema ilumina el iris y toma la imagen necesaria para realizar el

reconocimiento. Puede conectarse a ordenadores o integrado en un sistema
completo de seguridad (Travieso González, del Pozo Baños, & Ticay Rivas,
2011).
 Sistema lector de manos.
Es un sistema biométrico de geometría de mano que puede analizar más de

31000 de forma simultánea y registra más de 90 mediciones distintas incluidas
la longitud, ancho, espesor y superficie, para verificar que la persona que
utiliza el dispositivo es realmente quien él o ella afirma ser. El sistema
compara esta información con una "plantilla" de la mano del individuo que ha
sido previamente almacenado en el lector, en un servidor o en una tarjeta
(Travieso González, del Pozo Baños, & Ticay Rivas, 2011).
 Sistema de reconocimiento de venas.
La detección y captura se realiza sin contacto con la del lector e incluso las
palmas pueden estar en movimiento.
Esta tecnología captura los rasgos superiores de la palma de la mano, lo que

es muy difícil de falsificar porque mide un rasgo biométrico que está dentro del
55 de 274
cuerpo, es extensamente aplicable porque no se afecta con factores externos
y al no requerir contacto físico, las consideraciones sobre el factor higiénico le
dan una mayor aceptación (Travieso González, del Pozo Baños, & Ticay
Rivas, 2011).
 Sistema Combinado.
Estos sistemas incluyen identificación por huellas dactilares, cara, iris, tarjeta y
geometría de la mano. Cada tecnología biométrica tiene sus puntos fuertes y
sus limitaciones. No se espera que una tecnología sea efectiva para todas las
necesidades de todas las aplicaciones, sino que cada tecnología se adaptará
mejor o peor a cada aplicación.
Una comparativa de 14 diferentes tecnologías se muestra en la siguiente tabla

de la siguiente transparencia (Travieso González, del Pozo Baños, & Ticay
Rivas, 2011).
2.3.3. Funcionamiento de los dispositivos biométricos.
La mayoría de los sistemas biométricos funcionan con arreglo a un modelo general

que consiste en dos pasos (Figura 15). El primer paso es el registro de la persona en
el sistema. Durante el proceso de registro, el sistema captura el rasgo característico
de la persona, como por ejemplo la huella digital, y lo procesa para crear una
representación electrónica llamada modelo de referencia.
A continuación en el siguiente diagrama se muestra el funcionamiento de los

dispositivos biométricos, donde se ve la interacción que existe entre el dispositivo
biométrico y la base de datos, para el registro y la verificación de las características
de la huella dactilar se hace uso de un módulo de identificación, donde se aprecia
que se extraen las características para el registro y al obtener de la base de datos los
templates los compara con la lectura actual de la huella a ser verifica por el sistema,
para posteriormente mostrar el resultado obtenido.
56 de 274
Figura 15: Funcionamiento de los dispositivos biométricos.
Fuente: Travieso González, del Pozo Baños, & Ticay Rivas, 2011.
De acuerdo con la teoría tradicional en biometría, el segundo paso depende de si la

función del sistema biométrico consiste en verificar la identidad de la persona o
identificar a la persona.
En el caso de verificación, la persona le informa al sistema cuál es su identidad, ya

sea presentando una tarjeta de identificación o introduciendo alguna clave especial.
Se captura el rasgo biométrico y se compara con el modelo de referencia de la
persona. Si ambos modelos parean, la verificación se realizó con éxito, si no es
fallida.
En caso de que sea identificación, la persona no le informa al sistema biométrico cuál

es su identidad. El sistema tan sólo captura el rasgo biométrico y lo compara con un
conjunto de modelos de referencia para determinar la identidad de la persona.
57 de 274
2.3.4. Dispositivos biométricos de Control de Acceso y Asistencia.
2.3.4.1. TR-ICLOCK 260
Son equipos de Control de Presencia que permiten trabajar en modo autónomo (sin
PC), o integrarse fácilmente a una aplicación de Control de Presencia utilizando el
puerto RS-232/485 o mediante comunicación Ethernet así como descargando la
información en un Pen Drive / Flash Disk.
Características y ventajas
 Permite la visualización de mensajes a usuarios.

 Incorpora la opción de mostrar el Nombre (Alias) de la persona que está
fichando así como la respuesta del Terminal a través de voz pronunciando su
nombre.
 Distintos modos de operación: Sólo tarjetas, Código + Tarjeta y Código +
Password
 Incorpora puerto USB para la descarga de fichajes a una unidad portátil
(Pendrive o Flash Disk).
 Cambio de hora automático verano-invierno.
 Permite la respuesta del terminal al fichar a través de voz.
 Admite la introducción de ilimitadas incidencias (Fumar, Comida, Asuntos,
Médico, etc).
2.3.4.2. iFace402
Es una terminal de atención del tiempo de la identificación multi-biométrica y control

de acceso adopta la última plataforma ZEM600 de ZKSoftware con ZK Face 7.0
algoritmo y la memoria de gran capacidad. Procesador de alta velocidad ZK el Multi-
Bio serie iFace 630MHz integrado y la cámara infrarroja de alta definición permite la
identificación del usuario en el ambiente oscuro. Cara y método de identificación
multi-biométrico de huellas digitales serán aplicables más ampliamente. Todas las
operaciones del iFace se diseñan para ser realizadas en la pantalla táctil TFT de 4,3
58 de 274
pulgadas. Las comunicaciones del Multi-modelo incluyen RS232/485, TCP / IP, WiFi
opcional o GPRS. Opcional batería mAh incorporada en el año 2000 se elimina el
problema de las fallas del suministro eléctrico.
 Métodos de identificación incluyen la cara, Fingerprint / RFID y / o contraseña.

 Diseño ergonómico elegante pantalla táctil de 4.3'' TFT es muy intuitivo fácil de
usar y 6 definidos por el usuario las teclas de función relés de contacto para
el control de acceso de la puerta (alambres al tope de la puerta o el panel de
3° parte) software de gestión de servidor Web a través del navegador IE.
 Opcional extensible programada campana sistema óptico infrarrojo permite la
identificación del usuario en ambientes con poca luz opcional de copia de
seguridad incorporado en la batería proporciona aproximadamente 4 horas de
funcionamiento continuo.
 Opcional integrado en el inalámbricos GPRS Wi-Fi o por comunicación
inalámbrica incorporada contactos para cerradura 3 ª parte eléctrica, sensor
de puerta, alarma, botón de salida, o la campana.
 Salida Wiegand para las conexiones a los paneles de control de acceso
tercera parte.
2.3.4.3. DigitalPersona
Es ideal para las aplicaciones donde es de vital importancia la seguridad consistente

y confiable.
 Suave, resplandor azul fresco se adapta a cualquier entorno.

 Conserva espacio en el escritorio.
 Carcasa de metal de alta calidad ponderada para resistir el movimiento
involuntario.
 Óptica de alta calidad aseguran la mejor imagen cada vez.
59 de 274
 Rendimiento fiable sobre la población más amplia de usuarios. Lee incluso las
huellas digitales más difíciles.
Sistema de Control de personal beneficios y ventajas.
Según las necesidades y requerimientos de cada sistema de control de personal,

podemos adaptar la configuración y calcular automáticamente las horas trabajadas
por cada empleado durante todo el mes, o en el periodo en el cual se realiza el pago
de nómina. Esto se traduce en un aumento en la puntualidad de los empleados y en
una mayor productividad para la empresa.
 Mayor puntualidad y cumplimiento de todo el personal

 Disminución de horas improductivas
 Calculo automático de nómina según las horas reales trabajadas
 Aumento en la seguridad de toda la empresa
 Mejoramiento en la productividad
 Integración con otros sistemas de gestión y control en la empresa
 Reportes personalizados
 Ahorro en personal extra que lleve los registros manualmente
 Un mejor control de los visitantes
 Indicadores de gestión para tomar decisiones
2.4. INGENIERÍA DE SOFTWARE.
Una estructura general para la ingeniería de software define cinco actividades

estructurales: comunicación, planeación, modelado, construcción y despliegue.
Además, a lo largo de todo el proceso se aplica un conjunto de actividades sombrilla:
seguimiento y control del proyecto, administración de riesgos, aseguramiento de la
calidad, administración de la configuración, revisiones técnicas, entre otras (S.
Pressman, 2010).
60 de 274
2.4.1. Modelos de Desarrollo de software.
2.4.1.1. Modelo de proceso incremental.
Figura 16: El modelo incremental.
Fuente: S. Pressman, 2010.
En relación con la Figura 16, el modelo incremental es aquel que aplica secuencias
lineales en forma escalonada a medida que avanza el calendario. Cada secuencia
lineal produce incrementos de software susceptibles de entregarse de manera
parecida a los incrementos producidos en un flujo de proceso evolutivo.
Por ejemplo, un software para procesar textos que se elabore con el modelo
incremental quizá entregue en el primer incremento las funciones básicas de
administración de archivos, edición y producción del documento; en el segundo dará
herramientas más sofisticadas de edición y producción de documentos; en el tercero
habrá separación de palabras y revisión de la ortografía; y en el cuarto se
proporcionará la capacidad para dar formato avanzado a las páginas (S. Pressman,
2010).
Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea

el producto fundamental. Es decir, se realizan los requerimientos básicos, pero no se
61 de 274
proporcionan muchas características (algunas conocidas y otras no). El cliente usa el
producto fundamental (o lo somete a una evaluación detallada). Como resultado del
uso y/o evaluación, se desarrolla un plan para el incremento que sigue. Este incluye
la modificación del producto principal para cumplir mejor las necesidades del cliente,
así como la entrega de características adicionales y más funcionalidad. Este proceso
se repite después de entregar cada incremento, hasta terminar el producto final.
El modelo incremental aplica secuencias lineales en forma escalonada a medida que

avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de
software susceptibles de entregarse de manera parecida a los incrementos
producidos en un flujo de proceso evolutivo (S. Pressman, 2010).
El modelo de proceso incremental se centra en que en cada incremento se entrega

un producto operable. Los primeros incrementos son versiones con características
básicas del producto final.
Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea

el producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se
proporcionan muchas características suplementarias (algunas conocidas y otras no).
El cliente usa el producto fundamental (o lo somete a una evaluación detallada).
Como resultado del uso y/o evaluación, se desarrolla un plan para el incremento que
sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las
necesidades del cliente, así como la entrega de características adicionales y más
funcionalidad. Este proceso se repite después de entregar cada incremento, hasta
terminar el producto final (S. Pressman, 2010).
2.4.1.2. Modelo de Proceso Unificado.
El Proceso Unificado es más que sólo un proceso; es una estructura genérica de

proceso que puede especializarse para una clase muy grande de sistemas de
software, para diferentes áreas de aplicación, diferentes tipos de organizaciones,
diferentes niveles de competencia, y proyectos de diferentes tamaños. El Proceso
Unificado usa el Lenguaje de Modelación Unificado al preparar todos los modelos del
62 de 274
sistema de software. De hecho, UML es una parte integral del Proceso Unificado
fueron desarrollados al mismo tiempo. (Jacobson, Booch, & Rumbaugh, 2000)
UP se divide en cuatro fases como se aprecia en la siguiente figura:
Figura 17: Ciclo de vida del Proceso Unificado.
 Inicio (Define el alcance del proyecto)

 Elaboración (definición, análisis, diseño)
 Construcción (implementación)
 Transición (fin del proyecto y puesta en producción)
Inicio.
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más
esenciales (Jacobson, Booch, & Rumbaugh, 2000).
63 de 274
Elaboración.
El propósito de la fase de elaboración es analizar el dominio del problema, establecer

los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los
mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en

iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe
contener los Casos de Uso críticos identificados en la fase de inicio. También debe
demostrarse que se han evitado los riesgos más graves (Jacobson, Booch, &
Rumbaugh, 2000).
Construcción.
La finalidad principal de esta fase es alcanzar la capacidad operacional del producto

de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos
los componentes, características y requisitos deben ser implementados, integrados y
probados en su totalidad, obteniendo una versión aceptable del producto (Jacobson,
Booch, & Rumbaugh, 2000).
Transición.
La finalidad de la fase de transición es poner el producto en manos de los usuarios

finales, para lo que se requiere desarrollar nuevas versiones actualizadas del
producto, completar la documentación, entrenar al usuario en el manejo del producto,
y en general tareas relacionadas con el ajuste, configuración, instalación y facilidad
de uso del producto (Jacobson, Booch, & Rumbaugh, 2000).
2.4.1.3. Modelo de Espiral.
El modelo espiral es un modelo evolutivo del proceso del software y se acopla con la
naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del
modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de versiones
cada vez más completas (S. Pressman, 2010).
64 de 274
Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas
evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo
o prototipo. En las iteraciones posteriores se producen versiones cada vez más
completas del sistema cuya ingeniería se está haciendo.
Un modelo en espiral es dividido por el equipo de software en un conjunto de

actividades estructurales. Cada una de ellas representa un segmento de la
trayectoria espiral ilustrada en la figura 18. Al comenzar el proceso evolutivo, el
equipo de software realiza actividades en un circuito alrededor de la espiral en el
sentido horario, partiendo del centro (S. Pressman, 2010).
El primer circuito alrededor de la espiral da como resultado el desarrollo de una

especificación del producto; las vueltas sucesivas se usan para desarrollar un
prototipo y, luego, versiones cada vez más completas del software.
El modelo espiral es un enfoque realista para el desarrollo de sistemas y de software

a gran escala. Como el software evoluciona a medida que el proceso avanza, el
desarrollador y cliente comprenden y reaccionan mejor ante los riesgos en cada nivel
de evolución.
Figura 18: Modelo de espiral común.
65 de 274
Tiene dos características distintivas principales. La primera es el enfoque cíclico para
el crecimiento incremental del grado de definición de un sistema y su
implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto
de puntos de referencia de anclaje puntual para asegurar el compromiso del
participante con soluciones factibles y mutuamente satisfactorias (S. Pressman,
2010).
2.4.2. UML.
UML es ante todo un lenguaje. Un lenguaje que proporciona un vocabulario y una

reglas para permitir una comunicación. En este caso, este lenguaje se centra en la
representación gráfica de un sistema.
Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos.
Esto último es el objetivo de las metodologías de desarrollo.
Los objetivos de UML son muchos, entre los cuales se encuentran:
 Visualizar: UML permite expresar de una forma gráfica un sistema de forma

que otro lo puede entender.
 Especificar: UML permite especificar cuáles son las características de un
sistema antes de su construcción.
 Construir: A partir de los modelos especificados se pueden construir los
sistemas diseñados.
 Documentar: Los propios elementos gráficos sirven como documentación del
sistema des-arrollado que pueden servir para su futura re-visión.
Un modelo UML está compuesto por tres clases de bloques de construcción:
 Elementos: Los elementos son abstracciones de cosas reales o ficticias

(objetos, acciones, etc.)
 Relaciones: relacionan los elementos entre sí.
 Diagramas: Son colecciones de elementos con sus relaciones.
66 de 274
2.4.2.1. Diagramas UML.
Un diagrama es la representación gráfica de un conjunto de elementos con sus

relaciones. Es decir, un diagrama ofrece una vista del sistema a modelar. Para poder
representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. UML incluye los
siguientes diagramas:
 Diagrama de casos de uso.

 Diagrama de clases.
 Diagrama de objetos.
 Diagrama de secuencia.
 Diagrama de colaboración.
 Diagrama de estados.
 Diagrama de actividades.
 Diagrama de componentes.
 Diagrama de despliegue.
Los diagramas más interesantes (y los más usados) son los de casos de uso, clases
y colaboración.
Diagrama de Casos de Uso.
Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de

una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras
aplicaciones).
Los casos de uso se representan en el diagrama por una elipse que denota un
requerimiento solucionando por el sistema.
Diagrama de Clases.
Un diagrama de clases o estructura estática muestra el conjunto de clases y objetos

importantes que forman parte de un sistema, junto con las relaciones existentes entre
67 de 274
clases y objetos. Muestra de una manera estática la estructura de información del
sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con
los demás en el modelo.
Una clase es una entidad que define la estructura y comportamiento de una

colección de objeto denominados instancia de la clase. En UML la clase está
representada por un rectángulo con tres divisiones internas, son los elementos
fundamentales del diagrama.
Diagrama de Colaboración.
Estos son modelos que describen como los grupos de objetos que colaboran en
algunos ambientes, por lo general, un diagrama de interacción captura el
comportamiento de un único caso de uso. Hay dos tipos de diagramas de
interacción: diagramas de secuencia y diagramas de colaboración.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una

aplicación a través del tiempo. Esta descripción es importante porque puede dar
detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos
existentes, como también muestra el uso de los mensajes de las clases diseñadas en
el contexto de una operación
Un diagrama de colaboración es una forma de representar interacción entre los

objetos, es decir, las relaciones entre ellos y la secuencia de los mensajes de las
iteraciones que están indicadas por un número A diferencia de los diagramas de
secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos,
cuáles temporales,…) y ciclos en la ejecución.
2.4.3. Tipos de Pruebas
2.4.3.1. Estrategias de prueba para software convencional.
Existen muchas estrategias que pueden usarse para probar el software. En un

extremo, puede esperarse hasta que el sistema esté completamente construido y
luego realizar las pruebas sobre el sistema total, con la esperanza de encontrar
68 de 274
errores. Este enfoque, aunque atractivo, simplemente no funciona. Dará como
resultado software defectuoso que desilusionará a todos los participantes (S.
Pressman, 2010).
En el otro extremo, podrían realizarse pruebas diariamente, siempre que se

construya alguna parte del sistema. Este enfoque, aunque menos atractivo para
muchos, puede ser muy efectivo. Por desgracia, algunos desarrolladores de software
son reacios a usarlo. ¿Qué hacer? (S. Pressman, 2010).
Una estrategia de prueba que eligen la mayoría de los equipos de software se coloca
entre los dos extremos. Toma una visión incremental de las pruebas, comenzando
con la de unidades de programa individuales, avanza hacia pruebas diseñadas para
facilitar la integración de las unidades y culmina con pruebas que ejercitan el sistema
construido. Cada una de estas clases de pruebas se describe en las secciones que
siguen (S. Pressman, 2010).
Pruebas de Unidad.
La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña

del diseño de software: el componente o módulo de software. Al usar la descripción
del diseño de componente como guía, las rutas de control importantes se prueban
para descubrir errores dentro de la frontera del módulo.
La relativa complejidad de las pruebas y los errores que descubren están limitados
por el ámbito restringido que se establece para la prueba de unidad. Las pruebas de
unidad se enfocan en la lógica de procesamiento interno y de las estructuras de
datos dentro de las fronteras de un componente. Este tipo de pruebas puede
realizarse en paralelo para múltiples componentes (S. Pressman, 2010).
Consideraciones de las pruebas de unidad.
Las pruebas de unidad se ilustran de manera esquemática en la figura 19. La interfaz

del módulo se prueba para garantizar que la información fluya de manera adecuada
hacia y desde la unidad de software que se está probando.
69 de 274
Las estructuras de datos locales se examinan para asegurar que los datos
almacenados temporal mente mantienen su integridad durante todos los pasos en la
ejecución de un algoritmo.
Figura 19: Prueba de unidad.
Entre los potenciales errores que deben ponerse a prueba cuando se evalúa el
manejo de errores están:
 La descripción de error ininteligible,

 El error indicado no corresponde con el error que se encuentra,
 La condición del error causa la intervención del sistema antes de manejar el
error.
 La descripción del error no proporciona suficiente información para auxiliar en
la localización de la causa del error.
Procedimientos de prueba de unidad.
Las pruebas de unidad por lo general se consideran como unidas al paso de

codificación. El diseño de las pruebas puede ocurrir antes de comenzar la
codificación o después de generar el código fuente.
70 de 274
La revisión de la información del diseño proporciona una guía para establecer casos
de prueba que es probable que descubran errores en cada una de las categorías
analizadas anteriormente. Cada caso de prueba debe acoplarse con un conjunto de
resultados esperados.
Figura 20: Entorno de prueba de unidad.
Puesto que un componente no es un programa independiente, con frecuencia debe

desarrollarse software controlador y/o de resguardo para cada prueba de unidad. En
la figura 20 se ilustran los entornos de prueba de unidad. En la mayoría de las
aplicaciones, un controlador no es más que un “programa principal” que acepta datos
de caso de prueba, pasa tales datos al componente (que va a ponerse a prueba) e
imprime resultados relevantes (S. Pressman, 2010).
Pruebas de integración.
Las pruebas de integración son una técnica sistemática para construir la arquitectura
del software mientras se llevan a cabo pruebas para descubrir errores asociados con
71 de 274
la interfaz. El objetivo es tomar los componentes probados de manera individual y
construir una estructura de programa que se haya dictado por diseño (S. Pressman,
2010).
La integración incremental es la antítesis del enfoque big bang. El programa se

construye y prueba en pequeños incrementos, donde los errores son más fáciles de
aislar y corregir; las interfaces tienen más posibilidades de probarse por completo; y
puede aplicarse un enfoque de prueba sistemático (S. Pressman, 2010).
Pruebas de validación.
Las pruebas de validación comienzan en la culminación de las pruebas de

integración, cuando se ejercitaron componentes individuales, el software está
completamente ensamblado como un paquete y los errores de interfaz se
descubrieron y corrigieron. En el nivel de validación o de sistema, desaparece la
distinción entre software convencional, software orientado a objetos y webapps. Las
pruebas se enfocan en las acciones visibles para el usuario y las salidas del sistema
reconocibles por el usuario (S. Pressman, 2010).
La validación puede definirse en muchas formas, pero una definición simple (aunque
dura) es que la validación es exitosa cuando el software funciona en una forma que
cumpla con las expectativas razonables del cliente (S. Pressman, 2010).
Pruebas del sistema.
El software se incorpora con otros elementos del sistema (por ejemplo, hardware,
personas, información), y se lleva a cabo una serie de pruebas de integración y
validación del sistema. Estas pruebas quedan fuera del ámbito del proceso de
software y no se llevan a cabo exclusivamente por parte de ingenieros de software
(S. Pressman, 2010).
Sin embargo, los pasos que se toman durante el diseño y la prueba del software
pueden mejorar enormemente la probabilidad de integración exitosa del software en
el sistema más grande (S. Pressman, 2010).
72 de 274
Un problema clásico en la prueba del sistema es el “dedo acusador”. Esto ocurre
cuando se descubre un error y los desarrolladores de diferentes elementos del
sistema se culpan unos a otros por el problema. En lugar de abandonarse a tal sin
sentido, deben anticiparse los potenciales problemas de interfaz y: 1) diseñar rutas
de manejo de error que prueben toda la información proveniente de otros elementos
del sistema, 2) realizar una serie de pruebas que simulen los datos malos u otros
errores potenciales en la interfaz del software, 3) registrar los resultados de las
pruebas para usar como “evidencia” si ocurre el dedo acusador, y 4) participar en
planificación y diseño de pruebas del sistema para garantizar que el software se
prueba de manera adecuada (S. Pressman, 2010).
En realidad, la prueba del sistema es una serie de diferentes pruebas cuyo propósito
principal es ejercitar por completo el sistema basado en computadora. Aunque cada
prueba tenga un propósito diferente, todo él funciona para verificar que los elementos
del sistema se hayan integrado de manera adecuada y que se realicen las funciones
asignadas. En las secciones que siguen se estudian los tipos de pruebas del sistema
que valen la pena para los sistemas basados en software (S. Pressman, 2010).
2.5. TECNOLOGÍAS DE DESARROLLO.
Una herramienta de programación es un programa que usa generalmente un

programador para crear, depurar, gestionar o mantener un software. Además
algunas permiten realizar rutinas utilitarias y sistemas para que el hardware de la
computadora funcione, y pueda producir los resultados esperados. Las
herramientas de programación más comunes del mercado, cuentan hoy en día con
programas de depuración, que son utilitarios ya que nos permiten detectar los
posibles errores en tiempo de ejecución.
2.5.1. Lenguajes de programación.
Un lenguaje de programación es un convenio entre personas que puede definirse

así: Conjunto de reglas o normas que permiten asociar a cada programa correcto un
cálculo que será llevado a cabo por un ordenador (sin ambigüedades). Por tanto, un
73 de 274
lenguaje de programación es un convenio o acuerdo acerca de cómo se debe de
interpretar el significado de los programas de dicho lenguaje muchas veces se
confunden los lenguajes con los compiladores, intérpretes o con los entornos de
desarrollo de software (Ureña Almagro, 2011).
2.5.1.1. C# con ASP.NET.
C# (leído en inglés “C Sharp” y en español “C Almohadilla”) es el nuevo lenguaje de

propósito general diseñado por Microsoft para su plataforma .NET. Sus principales
creadores son Scott Wiltamuth y Anders Hejlsberg, éste último también conocido por
haber sido el diseñador del lenguaje Turbo Pascal y la herramienta RAD Delphi.
Aunque es posible escribir código para la plataforma .NET en muchos otros
lenguajes (González Seco, 2001).
C# es el único que ha sido diseñado específicamente para ser utilizado en ella, por lo
que programarla usando C# es mucho más sencillo e intuitivo que hacerlo con
cualquiera de los otros lenguajes ya que C# carece de elementos heredados
innecesarios en .NET. Por esta razón, se suele decir que C# es el lenguaje nativo de
.NET (González Seco, 2001).
Características.
 Sencillez.
C# elimina muchos elementos que otros lenguajes incluyen y que son

innecesarios en .NET (González Seco, 2001).
 Modernidad.
C# incorpora en el propio lenguaje elementos que a lo largo de los años ha ido

demostrándose son muy útiles para el desarrollo de aplicaciones y que en
otros lenguajes como Java o C++ hay que simular (González Seco, 2001).
74 de 274
 Orientación a objetos.
Como todo lenguaje de programación de propósito general actual, C# es un

lenguaje orientado a objetos, aunque eso es más bien una característica del
CTS que de C# (González Seco, 2001).
 Gestión automática de memoria.
Como ya se comentó, todo lenguaje de .NET tiene a su disposición el

recolector de basura del CLR. Esto tiene el efecto en el lenguaje de que no es
necesario incluir instrucciones de destrucción de objetos (González Seco,
2001).
 Seguridad de tipos.
C# incluye mecanismos que permiten asegurar que los accesos a tipos de

datos siempre se realicen correctamente, lo que permite evita que se
produzcan errores difíciles de detectar por acceso a memoria no perteneciente
a ningún objeto y es especialmente necesario en un entorno gestionado por
un recolector de basura (González Seco, 2001).
 Instrucciones seguras.
Para evitar errores muy comunes, en C# se han impuesto una serie de

restricciones en el uso de las instrucciones de control más comunes
(González Seco, 2001).
 Eficiente.
En principio, en C# todo el código incluye numerosas restricciones para

asegurar su seguridad y no permite el uso de punteros. Sin embargo, y a
diferencia de Java, en C# es posible saltarse dichas restricciones manipulando
objetos a través de punteros (González Seco, 2001).
75 de 274
2.5.1.2. Java.
Originalmente, Java no fue creado para la red Internet. La primera versión de Java
empezó en 1991 y fue escrita en 18 meses en Sun Microsystems. De hecho, en ese
momento, ni siquiera se llamó Java; se llamó Oak y se utilizó en Sun para uso
interno. La idea original para Oak era crear un lenguaje orientado a objetos
independiente de la plataforma. Por entonces, muchos programadores se limitaban a
la programación del IBM PC, pero el entorno corporativo podía incluir toda clase de
plataformas de programación, desde el PC hasta los grandes sistemas. Lo que había
detrás de Oak era crear algo que se pudiera usar en todos los ordenadores ( y ahora
que Java se ha hecho popular gracias a la red Internet, cada vez más corporaciones
están adoptándolo para uso interno en lugar de C++, precisamente por esa razón). El
lanzamiento original de Oak no fue especialmente fascinante; Sun quería crear un
lenguaje que se pudiera usar en electrónica (Holzner, 2000).
Oak pasó a llamarse Java en 1995, cuando se lanzó para el uso público y supuso un
éxito casi inmediato. En ese momento, Java había adoptado un modelo que lo hizo
perfecto para la red Internet, el modelo bytecode (Holzner, 2000).
Características.
 Orientado a Objeto.
Java da buen soporte a las técnicas de desarrollo OOP y en resumen a la

reutilización de componentes de software (uva, 2014).
 Distribuido.
Java se ha diseñado para trabajar en ambiente de redes y contienen una gran

biblioteca de clases para la utilización del protocolo TCP/IP, incluyendo HTTP
y FTP. El código Java se puede manipular a través de recursos URL con la
misma facilidad que C y C++ utilizan recursos locales (archivos) (uva, 2014).
76 de 274
 Interpretado.
El compilador Java traduce cada fichero fuente de clases a código de bytes

(Bytecode), que puede ser interpretado por todas las máquinas que den
soporte a un visualizador de que funcione con Java. Este Bytecode no es
especifico de una máquina determinada, por lo que no se compila y enlaza
como en el ciclo clásico, sino que se interpreta (uva, 2014).
 Seguro.
Como Java suele funcionar en ambiente de redes el tema de seguridad debe

interesar en sobremanera. Las mismas características antes descritas que
evitan la corrupción de código evitan su manipulación. Actualmente se esta
trabajando en encriptar el código (uva, 2014).
 Portable.
Al ser de arquitectura neutral es altamente portable, pero esta característica

puede verse de otra manera: Los tipos estándares (int, float...) están
igualmente implementados en todas las máquinas por lo que las operaciones
aritméticas funcionaran igual en todas las máquinas (uva, 2014).
 Alto desempeño.
El compilador Java suele ofrecer la posibilidad de compilar Bytecode en

código máquina de determinadas plataformas, y según Sun este código
resultar de una eficacia similar a compilaciones de C y C++ (uva, 2014).
 Multihilos.
Java puede aplicarse a la realización de aplicaciones en las que ocurra más

de una cosa a la vez. Java, apoyándose en un sistema de gestión de eventos
basado en el paradigma de condición y monitores C.A.R. permite apoyar la
conducta en tiempo real e interactiva en programas (uva, 2014).
77 de 274
2.5.1.3. Php.
PHP (acrónimo de "PHP: Hypertext Preprocessor") es un lenguaje interpretado de

alto nivel embebido en páginas HTML y ejecutado en el servidor (Sæther Bakken, y
otros, 2002).
Características.
 Autenticación http.
Es posible usar la función header() para enviar un mensaje "Authentication

Required" al navegador del cliente causando que se abra una ventana para
ingresar usuario y password (php, 2014).
 Cookies.
PHP soporta cookies HTTP de forma transparente. Las Cookies son un

mecanismo por el cual se almacenan datos en el browser remoto y así
rastrear o identificar a usuarios que vuelven (php, 2014).
 Sesiones.
El soporte de sesiones en PHP consiste en una manera de guardar ciertos

datos a través de diferentes accesos web. Esto permite crear aplicaciones
más personalizadas y mejorar las características del sitio web (php, 2014).
 Manejo de Xforms.
Define una variación de los webforms tradicionales los cuales permiten ser
usados en una gran variedad de plataformas y navegadores o inclusive en
medios no tradicionales como los documentos PDF (php, 2014).
78 de 274
2.5.2. IDE (Integrated Development Environment).
2.5.2.1. Visual Studio.
Visual Studio es una completa colección de herramientas y servicios para el

desarrollo de aplicaciones destinadas a la computadora, Internet, los dispositivos y la
nube. Si va a crear su primera aplicación de Windows Store, o la construcción de un
sitio web para apoyar a las últimas versiones de navegadores, puede aprovechar sus
habilidades existentes con el entorno de desarrollo de estado-of-the-art de Visual
Studio para. NET, HTML / JavaScript y C + +. Para los equipos de trabajo a través de
múltiples plataformas, Visual Studio proporciona un entorno de colaboración flexible
para que acoja la conexión con otras herramientas de desarrollo, como Eclipse y
Xcode (Studio, 2014).
Características.
Entre las características de Visual Studio se encuentran las siguientes:
 Entorno de desarrollo.
Se Centra en crear valor y realizar antes el trabajo con un entorno de

desarrollo limpio, rápido y con un gran potencial.
 Pantalla informativa CodeLens.

 Entorno muy completo.
 Desarrollo de aplicaciones empresariales.
 Compatibilidad con plataformas.
Compila aplicaciones dirigidas a plataformas de Microsoft, así como

aplicaciones web móviles, otras aplicaciones web y servicios en la nube en
diferentes dispositivos.
 Aplicaciones Windows.
 Aplicaciones web y servicios en la nube.
 Aplicaciones de producción.
79 de 274
 Depuración y diagnóstico.
Identifica y soluciona problemas que impiden que tu aplicación se ejecute

correctamente, independientemente de la plataforma.
 Depurador avanzado.
 Browser Link.
 IntelliTrace.
 Herramientas para pruebas de software.
Herramientas para pruebas avanzadas garantizan la calidad a lo largo del

ciclo de vida de una aplicación, lo que permite obtener software de alta
calidad.
 Administración de casos de prueba.

 Pruebas de rendimiento web.
 Pruebas de carga.
 Arquitectura y modelado.
Herramientas muy completas e intuitivas de modelado y elaboración de

diagramas para visualizar, analizar y validar la arquitectura del software.
 Diagramas UML.
 Mapa del código.
 Explorador de arquitectura.
2.5.2.2. NetBeans.
NetBeans IDE proporciona de primera clase de apoyo integral para las tecnologías
Java más recientes y las últimas mejoras de la especificación de Java antes de que
otros IDEs. Es el primer IDE libre que proporciona soporte para JDK 8 avances, JDK
7, Java EE 7 incluyendo sus mejoras de HTML5 relacionados y JavaFX 2. Con su
constante mejora Java Editor, muchas características avanzadas y una amplia gama
80 de 274
de herramientas, plantillas y muestras, NetBeans IDE establece el estándar para el
desarrollo de tecnologías de vanguardia de la caja (Florentino López).
Características.
 Soporte JavaScript.
 Sintaxis Resaltada.
 Completación de Código y Análisis de Tipeo.
 Soluciones Rápidas (Quick Fixes) y Verificación de Sintaxis.
 Refactorización.
 Mejoras en el Desempeño.
 Inicio hasta 40% más rápido.
 Promociones más inteligentes, así que la completación de código es
más rápida.
 Menor consumo de memoria.
 Soporte para los Web APIs Más Usados.
 Fácil creación de aplicaciones remezcladas (mashup).
 Operaciones de Arrastrar y soltar dentro del entorno POJO, Servlet,
JSP y servicios web RESTful para que NetBeans IDE genere todo el
código para acceder a los servicios.
 Soporte de web APIs tales como Google, Facebook, Yahoo y YouTube.
 Nuevas Extensiones (Plugins).
 Control de versión ClearCase.
 Soporte AXIS.
 Soporte SOAP UI.
 Java Mobility (Aplicaciones para Móbiles).
 Emulador Mpowerplayer MIDP para aplicaciones MIDP en MacOS X
(disponible en el centro de extensiones).
 Estructurador SVG (SVG Composer) para Componentes SVG de Uso
Frecuente (SVG Custom Components).
 Documentación y estabilidad mejoradas.
81 de 274
2.5.2.3. Eclipse.
El Proyecto Eclipse fue creado originalmente por IBM en noviembre de 2001 y con el
apoyo de un consorcio de proveedores de software. La Fundación Eclipse fue creada
en enero de 2004 como una corporación independiente sin fines de lucro para que
actúe como administrador de la comunidad Eclipse. La corporación independiente sin
fines de lucro fue creada para permitir que un proveedor neutral y abierto,
comunitario transparente que se establecerá en torno a Eclipse. Hoy en día, la
comunidad Eclipse consiste en individuos y organizaciones de una sección
transversal de la industria del software (Eclipse, 2014).
Características.
 Control de versión y gestión de configuración.

 CVS.
 Merant PVCS.
 Rational ClearCase.
 Modelaje UML.
 OMONDO EclipseUML.
 Rational XDE (remplaza a Rose).
 Junto con la Edición de WebSphere Studio.
 Gráficos.
 Batik SVG.
 Macromedia Flash.
 Desarrollo Web, HTML, XML.
 Macromedia Dreamweaver.
 XMLBuddy.
 Integración del Servidor de Aplicaciones.
 Lanzador Sysdeo Tomcat.
82 de 274
2.5.3. Frameworks.
2.5.3.1. CodeIgniter.
Es un framework de aplicaciones web de código abierto para ayudar a escribir

programas PHP. El objetivo de la aplicación es ayudar a los desarrolladores de
proyectos de código más rápido que escribir código desde cero. Esto se logrará
ofreciendo un amplio conjunto de librerías para tareas comunmente necesarias, así
como una interfaz sencilla y la estructura lógica para acceder a estas bibliotecas.
CodeIgniter se basa libremente en el patrón de desarrollo Model-View-Controller

popular. CodeIgniter es más a menudo que destaca por su velocidad en comparación
con otros frameworks PHP.
Las características incluyen:
 Clases de base de datos con todas las funciones con soporte para varias
plataformas.
 Ajax.
 Forma y Validación de Datos.
 Gestión de la sesión.
 Marcos de migración DB.
 Marcos de seguridad.
 Marcos de plantilla.
 Marcos de validación de formularios.
 Cifrado de datos.
 Gran biblioteca de funciones "ayudantes".
2.5.3.2. .NET.
Es un framework de Microsoft que hace un énfasis en la transparencia de redes, con

independencia de plataforma de hardware y que permita un rápido desarrollo
de aplicaciones. Basado en ella, la empresa intenta desarrollar una estrategia
83 de 274
horizontal que integre todos sus productos, desde el sistema operativo hasta las
herramientas de mercado.
NET podría considerarse una respuesta de Microsoft al creciente mercado de los

negocios en entornos Web, como competencia a la plataforma Java de Oracle
Corporation y a los diversos framework de desarrollo web basados en PHP. NET
ofrece una manera rápida y económica, a la vez que segura y robusta, de desarrollar
aplicaciones, permitiendo una integración más rápida y ágil entre empresas y un
acceso más simple y universal a todo tipo de información desde cualquier tipo de
dispositivo.
Entre las características de .NET se encuentran:
 Cargador de clases: permite cargar en memoria las clases.
 Compilador MSIL a nativo: transforma código intermedio de alto nivel

independiente del hardware que lo ejecuta a código de máquina propio del
dispositivo que lo ejecuta.
 Administrador de código: coordina toda la operación de los distintos subsistemas

del Common Language Runtime.
 Recolector de basura: elimina de memoria objetos no utilizados automáticamente.
 Motor de seguridad: administra la seguridad del código que se ejecuta.
 Motor de depuración: permite hacer un seguimiento de la ejecución del código

aun cuando se utilicen lenguajes distintos.
 Verificador de tipos: controla que las variables de la aplicación usen el área de

memoria que tienen asignado.
 Administrador de excepciones: maneja los errores que se producen durante la

ejecución del código.
84 de 274
 Soporte de multiproceso (hilos): permite desarrollar aplicaciones que ejecuten
código en forma paralela.
 Empaquetador de COM: coordina la comunicación con los componentes COM

para que puedan ser usados por el .NET Framework.
2.5.3.3. Java Server Faces.
Java Server Faces (JSF) es una tecnología y framework para

aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de
usuario en aplicaciones Java EE. JSF usa Java Server Pages (JSP) como la
tecnología que permite hacer el despliegue de las páginas, pero también se puede
acomodar a otras tecnologías como XUL (acrónimo de XML-based User-interface
Language, lenguaje basado en XML para la interfaz de usuario).
JSF incluye:
 Un conjunto de APIs para representar componentes de una interfaz de usuario

y administrar su estado, manejar eventos, validar entrada, definir un esquema
de navegación de las páginas y dar soporte para internacionalización y
accesibilidad.
 Un conjunto por defecto de componentes para la interfaz de usuario.
 Dos bibliotecas de etiquetas personalizadas para Java Server Pages que
permiten expresar una interfaz Java Server Faces dentro de una página JSP.
 Un modelo de eventos en el lado del servidor.
 Administración de estados.
 Beans administrados.
2.5.4. Mecanismos de seguridad.
2.5.4.1. SHA-512.
SHA-512 es una variante de SHA-256 que opera en ocho palabras de 64 bits.
85 de 274
La función de compresión de SHA-512 opera en un bloque de mensaje de 1024 bits
y un valor hash intermedio de 512 bits. Se trata esencialmente de un algoritmo de
cifrado de bloques de 512 bits que cifra el valor de hash de interpolación en el bloque
de mensaje como clave. Por lo tanto hay dos componentes principales para describir:
la función de compresión de SHA-512, y el calendario mensaje SHA-512.
2.5.4.2. Log’s de usuarios con C# y Oracle.
El log de usuarios es una herramienta dentro de un sistema que permite guardar

datos relevantes para poder generar reportes de ingreso de los usuarios. Así mismo
permite a la empresa crear estadísticas de que empleados son los que ingresan con
más frecuencia al sistema y cuáles son las horas que puedan generar cuello de
botella en el sistema.
2.5.5. Generadores de Reportes.
2.5.5.1. Agata.
Agata Report es un generador de reportes multi-plataforma, una herramienta de

consulta y generación de gráficos como el Crystal Reports que se conecta a várias
Bases de Datos, como PostgreSQL, MySQL, Oracle, DB2, MS-SQL, Informix,
InterBase, Sybase, o Frontbase y permite exportar los reportes en formatos como
PostScript, plain text, HTML, XML, PDF o CSV (StarCalc, Excel). Permite definir
niveles de datos, subtotales y totales para el relatorio. Permite crear documentos,
como cartas y conjugar dinamicamente con los datos provenientes del reporte, asi
como crear etiquetas de direccionamiento y hasta generar un diagrama ER completo
apartir de su banco de datos (libres, 2014).
2.5.5.2. Crystal Reports.
Crystal Reports para Visual Studio .NET es la herramienta de elaboración de

informes estándar para Visual Studio .NET. Permite crear contenido interactivo con
calidad de presentación en la plataforma .NET, lo que ha supuesto una ventaja
fundamental para Crystal Reports durante años (Network, Crystal Reports, 2014).
86 de 274
Crystal Reports para Visual Studio proporciona una forma muy productiva de crear e
integrar informes interactivos con calidad de presentación en las aplicaciones para
Windows, Web o servicios Web XML. El diseñador gráfico incrustado permite crear
fácilmente informes desde el IDE y minimiza la codificación intensiva asociada al
desarrollo de informes (Network, Crystal Reports, 2014).
2.5.5.3. Codisa Query Builder.
Codisa query builder en su versión standard y professional, es una herramienta para

generar y compartir consultas y reportes a partir de las diferentes fuentes de datos
con las que cuente su organización (Codisa, 2014).
2.6. SISTEMAS DE GESTIÓN DE BASES DE DATOS.
2.6.1. SQL Server.
El fundamento de la plataforma de datos completa de Microsoft, SQL Server ofrece

un extraordinario rendimiento para aplicaciones de misión crítica, utilizando
tecnologías, ideas rápidas de datos a cualquier usuario de herramientas familiares
como Excel, y una plataforma flexible para la creación, implementación y gestión
soluciones que abarcan bajo premisa y nube (Microsoft, 2014).
Características.
SQL Server Management Studio incluye las siguientes características generales:
 Compatibilidad con la mayoría de las tareas administrativas de SQL Server.

 Un entorno único integrado para la administración del Motor de base de datos
de SQL Server y la creación.
 Cuadros de diálogo para administrar objetos de Motor de base de datos de
SQL Server, Analysis Services y Reporting Services, lo que permite ejecutar
las acciones inmediatamente, enviarlas a un editor de código o escribirlas en
script para ejecutarlas posteriormente.
87 de 274
 Exportación e importación del registro de servidor de SQL Server Management
Studio desde un entorno de Management Studio a otro.
 Guardado o impresión de archivos de plan de presentación XML o de
interbloqueo generados por SQL Server Profiler, revisión posterior o envío a
los administradores para su análisis.
 Un nuevo cuadro de mensaje de error e informativo que presenta mucha más
información, permite enviar a Microsoft un comentario sobre los mensajes,
copiar mensajes en el Portapapeles y enviar fácilmente los mensajes por
correo electrónico al equipo de soporte.
 Un explorador web integrado para una rápida exploración de MSDN o la
Ayuda en pantalla.
Beneficios.
SQL Server 2014 hace que sea más fácil y más costo efectiva para construir de alto
rendimiento y aplicaciones de misión crítica, lista para la empresa los activos de
grandes datos y soluciones de BI que ayudan a los empleados a tomar mejores
decisiones, más rápido. Estas soluciones tienen la flexibilidad de ser desplegado en
las instalaciones, en la nube o en un entorno híbrido, y se pueden gestionar a través
de un conjunto de herramientas común y familiar (Microsoft, 2014).
2.6.2. Oracle.
La base de datos Oracle es compatible con medianas industrias. Esta incluye Real
Application Clúster para proporcionar protección en contra de fallos de hardware. Es
fácil de instalar y configurar, viene con su propio software de clustering,
administración de almacenamiento y otras capacidades de auto administración. La
base de datos Oracle administra todos sus datos y permite que todas sus
aplicaciones de negocio tomen ventaja del rendimiento, seguridad y confiabilidad que
proporciona la base de datos Oracle. También brinda la flexibilidad de poder migrar a
la versión Enterprise Edition, protegiendo su inversión a medida que los
requerimientos de su negocio crecen (ORACLE, 2014).
88 de 274
La Base de datos Oracle esta optimizada para su despliegue en medianas industrias.
Está disponible en todos los sistemas operativos soportados por Oracle entre los
cuales se incluye Windows, Linux y Unix (ORACLE, 2014).
Características.
 Oracle NET es el responsable de comunicar el cliente y el servidor y

viceversa.
 Puede estar configurado en el cliente.
 Oracle NET soporta productos middleware como: Oracle Application Manager
y el Oracle Connection Manager.
 Oracle NET soporta una variedad de protocolos como TCP y named pipes.
 Oracle Advanced Security provee herramientas de seguridad para transmitir la
información (utiliza mecanismos de encriptación) y mecanismos de
autentificación confiable a los usuarios en el Oracle Enterprise.
 Hostnaming, son para pequeñas redes, reduce la cantidad de configuración
necesaria, permite olvidarse de la configuración del cliente. Requisitos: Usar
TCP/IP, no se debe usar características de red avanzada como Oracle
Connection Manager, debe existir una resolución de nombres tal como un
DNS o hosts files además lo más importante que el listener debe estar
seteado con el parametro GLOBAL_DBNAME con el nombre de la maquina
(Se configura en la sección SID_LIST_NOMBRE_LISTENER). El cliente no
requiere configuración, solo ingresar en el sqlnet.ora (HOSTNAME). Si se
tiene varias base de datos en una misma maquina hay que especificar en el
archivo hosts del cliente 2 entradas con el mismo ip pero diferente alias
además cada listener.ora ingresar en el GLOBAL_DBNAME el nombre del
alias correspondiente y el servidor debe tener varios nombres de resolución.
Para conectarse: user/password@hostservidor.
 En Easy Connect si el nombre de la instancia es igual al nombre del servidor
se omite el nombre del servicio al igual si está usando el puerto 1521 por
default.
89 de 274
 Cuando el listener no está levantado no se puede entrar al Database Control.
Muestra el siguiente error (The network adapter could not establish the
connection).
Todos los datos, todas las aplicaciones
Oracle como la base de datos líder del mercado soporta todos los tipos de datos
relacionales estándares, así como también datos nativos como XML, texto,
imágenes, documentos, audio, y datos espaciales. El acceso a la información es
realizado a través de interfaces estándares como SQL, JDBC, SQLJ, ODBC.Net,
OLE.Net y ODP.Net, SQL/XML, XQuery y WebDAV. Los procedimientos
almacenados pueden ser escritos en Java, PL/SQL o utilizando .Net CLR support en
Oracle Database (ORACLE, 2014).
2.6.3. MySQL.
MySQL, el sistema de gestión de bases de datos SQL Open Source más popular, lo
desarrolla, distribuye y soporta MySQL AB. MySQL AB es una compañía comercial,
fundada por los desarrolladores de MySQL. Es una compañía Open Source de
segunda generación que une los valores y metodología Open Source con un exitoso
modelo de negocio (MySQL, 2014).
Características.
Interioridades y portabilidad.
 Escrito en C y en C++.
 Probado con un amplio rango de compiladores diferentes.
 Funciona en diferentes plataformas.
 Usa GNU Automake, Autoconf, y Libtool para portabilidad.
 APIs disponibles para C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, y Tcl.
Consulte Capítulo 24, APIs de MySQL.
90 de 274
 Uso completo de multi-threaded mediante threads del kernel. Pueden usarse
fácilmente multiple CPUs si están disponibles.
 Proporciona sistemas de almacenamiento transaccional y no transaccional.
 Relativamente sencillo de añadir otro sistema de almacenamiento. Esto es útil

si desea añadir una interfaz SQL para una base de datos propia.
 Un sistema de reserva de memoria muy rápido basado en threads.
 Joins muy rápidos usando un multi-join de un paso optimizado.
 Tablas hash en memoria, que son usadas como tablas temporales.
 Las funciones SQL están implementadas usando una librería altamente

optimizada y deben ser tan rápidas como sea posible. Normalmente no hay
reserva de memoria tras toda la inicialización para consultas.
 El servidor está disponible como un programa separado para usar en un

entorno de red cliente/servidor. También está disponible como biblioteca y
puede ser incrustado (linkado) en aplicaciones autónomas. Dichas
aplicaciones pueden usarse por sí mismas o en entornos donde no hay red
disponible.
Seguridad.
 Un sistema de privilegios y contraseñas que es muy flexible y seguro, y que

permite verficación basada en el host. Las contraseñas son seguras porque
todo el tráfico de contraseñas está cifrado cuando se conecta con un servidor.
Escalabilidad y límites.
 Soporte a grandes bases de datos. Usamos MySQL Server con bases de

datos que contienen 50 millones de registros. También conocemos a usuarios
91 de 274
que usan MySQL Server con 60.000 tablas y cerca de 5.000.000.000.000 de
registros.
 Se permiten hasta 64 índices por tabla (32 antes de MySQL 4.1.2). Cada
índice puede consistir desde 1 hasta 16 columnas o partes de columnas. El
máximo ancho de límite son 1000 bytes (500 antes de MySQL 4.1.2).
Conectividad.
 Los clientes pueden conectar con el servidor MySQL usando sockets TCP/IP
en cualquier plataforma. En sistemas Windows de la familia NT (NT,2000,XP,
o 2003), los clientes pueden usar named pipes para la conexión. En sistemas
Unix, los clientes pueden conectar usando ficheros socket Unix.
 En MySQL 5.0, los servidores Windows soportan conexiones con memoria
compartida si se inicializan con la opción --shared-memory. Los clientes
pueden conectar a través de memoria compartida usando la
opción protocol=memory.
Localización.
 El servidor puede proporcionar mensajes de error a los clientes en muchos

idomas.
 La ordenación se realiza acorde al conjunto de caracteres elegido (usando
colación Sueca por defecto). Es posible cambiarla cuando arranca el servidor
MySQL.
Clientes y herramientas.
 MySQL server tiene soporte para comandos SQL para chequear, optimizar, y
reparar tablas. Estos comandos están disponibles a través de la línea de
comandos y el cliente mysqlcheck. MySQL también incluyemyisamchk, una
utilidad de línea de comandos muy rápida para efectuar estas operaciones en
tablas MyISAM.
92 de 274
3.1. DISEÑO DEL MODELADO DE NEGOCIO ACTUAL PARA EL
PROCESO DE CONTROL DE PERSONAL.
Para realizar el diseño de procedimientos para el control de personal, se realizara la

descripción de los procesos que están involucrados en el control de personal del
Gobierno Municipal Autónomo de Cochabamba y el modelado de negocio actual, que
describe los procedimientos actuales para realizar el proceso de control de personal
para los funcionarios públicos de la institución.
3.1.1. Diseño del modelado de negocio actual para el control de kardex.
 Registro de un archivo personal de un funcionario.

 Verificación de la documentación del archivo personal del funcionario público.
 Almacenamiento de los documentos personal.
 Búsqueda de archivos del file personal.
Figura 21: Diagrama de modelado de negocio actual de control de kardex.
Inicio
Inicio
El
El funcionario
funcionario público
público pasa
pasa
satisfactoriamente
satisfactoriamente todas
todas las
las
pruebas
pruebas establecidas
establecidas por
por el
el
subsistema
subsistema de
de dotación
dotación de
de
personal
personal en
en actual
actual vigencia
vigencia
El
El Gobierno
Gobierno municipal
municipal autónomo
autónomo de de
cochabamba
cochabamba contrata
contrata alal funcionario
funcionario
público
público extendiendole
extendiendole para
para esto
esto un
un
memorandum
memorandum firmado
firmado por
por la
la maxima
maxima
autoridad
autoridad dede la
la institucion
institucion
93 de 274
El
El funcionario
público se
se
apersona
apersona ala
ala dirección
dirección de
de
recursos
recursos humanos
humanos alal area
area de
de
archivos
archivos
El
El funcionario
público solicita
solicita aa la
la
encargada
encargada de
de la
la recepcion
recepcion dede
documentos
documentos la la lista
lista de
de requisios
requisios
para
para el
el archivo
archivo personal
personal
La
La encargada
encargada lele entrega
entrega una
una hoja
hoja al
al
funcionario
funcionario publico
publico con
con la
la lista
lista de
de
requisitos
requisitos para
para el
el archivo
archivo persona
persona
los
los mismos
mismos que
que se
se detallan
detallan aa
continuación
continuación
 Hoja
Hoja de
de kardex
kardex
 Fotografias
Fotografias
 Formulario
Formulario de
de incompatibilidad
incompatibilidad
 Croquis
Croquis de
de domicilio
domicilio
 Fotocopia
Fotocopia de
de CI
CI
 Curriculum
Curriculum vitae
vitae
 Titulo
Titulo en
en Prov.
Prov. Nac.
Nac.
 Declaración
Declaración jurada
jurada
 Certificado
Certificado de
de nacimiento
nacimiento
 Certificado
Certificado de
de matrimonio
matrimonio
 Certificado
Certificado de
de nacimiento
nacimiento
dependientes
dependientes
 Seguro
Seguro de
de salud
salud
 AFP
AFP NUA
NUA
La
La encargada
encargada del del area
area de
de archivos
archivos lele
indica
indica la
la fecha
fecha enen la
la cual
cual en
en el
el
funcionario
funcionario debedebe aproximarse
aproximarse aa las
las
oficinas
oficinas aa dejar
dejar la
la documentacion
documentacion
exigida
exigida por
por la
la institucion
institucion yy anota
anota en
en unun
libro
libro de
de registro
registro
El
El funcionario
funcionario se
se retira
retira de
de la
la
institucion
institucion con
con la
la lista
lista de
de
requisitos
requisitos de
de los
los documentos
documentos
que
que debe
debe presentar
presentar
94 de 274
El
El funcionario
funcionario publico
publico en
en la
la fecha
fecha
establecida
establecida se
se apoxima
apoxima aa la
la
direccion
direccion de
de recursos
recursos humanos
humanos al al
area
area de
de archivos
archivos donde
donde debe
debe
entregar
entregar la
la documentacion
documentacion
EL
EL funcionario
funcionario publico
publico indica
indica aa la
la
encargada
encargada que
que se
se le
le dijo
dijo que
que
entregue
entregue esa
esa fecha
fecha susu
documentacion
documentacion para
para su
su archivo
archivo
personal
personal
La
La encargada
encargada dede archivos
archivos
verifica
verifica en
en el
el libro
libro de
de
registros
registros el
el nombre
nombre yy el
el ci
ci
del
del funcinoario
funcinoario publico
publico
El
El funcionario
funcionario publico
publico se
se retira
retira la
la
¿Es
¿Es la
la fecha
fecha No institucion
institucion yy vuelve
vuelve en
en la
la fecha
fecha
establecida?
establecida? establecida
establecida con
con susu documentacion
documentacion
Si
La
La encargada
encargada dede archivos
archivos
realiza
realiza la
la recepcion
recepcion de
de la
la
documentacion
documentacion deldel
funcionario
funcionario publico
publico
La
La encargada
encargada revisa
revisa uno
uno aa unos
unos los
los
documentos
documentos si si estos
estos se
se encuentran
encuentran en en el
el
orden
orden establecido
establecido yy cumplen
cumplen con
con la
la lista
lista de
de
requisitos
requisitos establecidos
establecidos
El
El funcionario
funcionario publico
publico debe
debe ¿El
¿El archivo
archivo
presentar
presentar la la documentacion
documentacion No personal
personal esta
esta
faltante
faltante del
del archivo
archivo personal
personal para
para completo?
completo?
la
la institucion
institucion
Si
La
La encargada
encargada adjunta
adjunta la
la lista
lista
de
de requisitos
requisitos al
al archivo
archivo
personal
personal del
del funcionario
funcionario
publico
publico recien
recien entregado
entregado
La
La encargada
encargada registra
registra en
en el
el libro
libro
que
que el
el funcionario
funcionario entrego
entrego enen
fecha establecida la
fecha establecida la
documentacion completa
documentacion completa
95 de 274
La encargada de adiciona La
La encargada
encargada almacena
almacena el
el archivo
archivo
1 la justificación del personal
personal del
del funcionario
funcionario publico
publico en
en los
los
funcionario publico armarios
armarios destinados
destinados para
para ese
ese fin
fin
Cuando
Cuando un
un jefe
jefe de
de departamento
departamento solicita
solicita la
la
documentacion
documentacion deldel funcionario
funcionario por
por
cualquier
cualquier motivo
motivo la
la encargada
encargada realiza
realiza la
la
busqueda
busqueda dede la
la documentacion
documentacion
La
La encargada
encargada realiza
realiza la
la busqueda
busqueda en
en los
los
diferentes
diferentes armarios
armarios donde
donde se se encuentran
encuentran los
los
archivos
archivos personales
personales de
de los
los funcionario
funcionario publicos
publicos
La
La encargada
encargada de de kardex
kardex indica
indica aa la
la persona
persona
¿Encontro
¿Encontro la
la que
que solicito
solicito la
la documentacion
documentacion que que esta
esta no
no
No
documentacion?
documentacion? esta
esta disponible
disponible por
por haberse
haberse extraviado
extraviado oo
por
por algun
algun otro
otro motivo
motivo
Si
La
La encargada
encargada indica
indica al
al jefe
jefe de
de La
La persona
persona que
que lo
lo necesita
necesita se
se molesta
molesta
departamento
departamento queque encontro
encontro lala por
por que
que no
no esta
esta disponible
disponible la
la
documentacion
documentacion deldel funcionario
funcionario informacion
informacion del
del funcionario
funcionario que
que
publico
publico que
que este
este solicito
solicito necesita
necesita
El
El jefe
jefe de
de departamento
departamento envia
envia aa una
una
persona
persona para
para que
que recoja
recoja la
la documentacion
documentacion
de
de la
la direccion
direccion de
de recursos
recursos humanos
humanos deldel
area
area de
de archivos
archivos
La
La encargada
encargada entrega
entrega la
la
documentacion
documentacion del del funcionario
funcionario
publico
publico aa la
la persona
persona que
que envio
envio el
el
empleado
empleado que que lo
lo necesita
necesita
Posteriormente
Posteriormente el
el que
que solicito
solicito la
la
documentacion
documentacion se se aproxima
aproxima aa
devolver
devolver el
el archivo
archivo personal
personal del
del
funcionario
funcionario publico
publico
Fin
Fin
96 de 274
3.1.2. Diseño del modelado de negocio actual para el control de asistencia.
 Registro de un nuevo funcionario público.

 Registro del funcionario público en el dispositivo biométrico.
 Pruebas de reconocimiento de rasgos físicos de la persona.
Figura 22: Diagrama de modelado de negocio actual de control de asistencia.
Inicio
El nuevo funcionario público es

citado por la institución para
realizar el registro en el dispositivo
biométrico
El funcionario público se
aproxima a la institución para
realizar el registro de sus
características físicas
correspondientes
El encargado realiza el
registro del rostro del
funcionario de acuerdo al
siguiente detalle
97 de 274
 Para poder realizar el reconocimiento
facial, la persona no debe de realizar
ningún gesto en la cara, al momento de
registro.
 La postura debe de ser firme sin realizar

movimiento alguno durante el registro.
El encargado realiza el
registro de sus huellas
dactilares del
funcionario
¿El funcionario Se realiza el registro del

tiene algún No dedo índice, el dedo
impedimento? medio y el dedo anular.
Si
Si el funcionario tiene algun

impedimento en alguno de los dedos se
registra otro dedo como alternativa
El encargado realiza el registro del

funcionario en el software
integrado del dispositivo
biométrico
El encargado le entrega al
funcionario su clave de acceso para
el registro de entrada y salida de
institucion
98 de 274
La fecha que el funcionario ingresa a
trabajar según su memorandum este se
aproxima a la institución y marca el
horario de ingreso
Debe presentar justificativo al

El sistema del
¿Marco horario de encargado de control de ¿Falta es
No No dispositivo se 2
ingreso? asistencia por haber faltado a la justificada?
registra con falta
institución en día laboral
Si
Si
El sistema registra El encargado remite la

¿Marco ingreso retraso debido a que le justificación al area de
No
antes de las 8? funcionario marco en kardex para que este sea
horario no establecido archivado
Si
1
EL funcionario se dirige al area de
trabajo que le corresponde
Al llegar las 12 del medio dia

el funcionario se dirige a
marcar su salida de la
institucion
El sistema del
EL funcionario debe
¿Marco horario ¿No marcación dispositivo no sufre
No presentar justificativo del No 2
de salida? justificada? ninguna
motivo por el que no marco
modificación
El funcionario se Si
retira de la
institución a su
descanso de dos El encargado remite la justificación al area
1
horas y media de kardex para que este sea archivado
Debe presentar justificativo al

El sistema del
¿Marco horario de encargado de control de ¿Falta es
No No dispositivo se 2
ingreso? asistencia por haber faltado a la justificada?
registra con falta
institución en día laboral
Si Si
El sistema registra El encargado remite la

¿Marco ingreso retraso debido a que le justificación al area de
No
antes de las 14:30? funcionario marco en kardex para que este sea
horario no establecido archivado
Si
1
EL funcionario se dirige al area de
trabajo que le corresponde
99 de 274
Al llegar las 18:30 el
funcionario se dirige a
marcar su salida de la
institucion
El sistema del
EL funcionario debe
¿Marco horario ¿No marcación dispositivo no sufre
No presentar justificativo del No 2
de salida? justificada? ninguna
motivo por el que no marco
modificación
Si
El funcionario se retira de
la institución y se da por
finalizada la jornada El encargado remite la
laboral justificación al area de
kardex para que este sea
archivado
El encargado
verifica la fecha
según calendario 1
El dia 20 de cada mes el

encargado de control de
asistencia realiza la
exportación de los datos del
dispositivo biométrico al
sistema en Visual basic
En el sistema de visual basic el

encargado realiza la generacion de la
planilla de asistencia del mes
correspondiente y lo remite al area
de sueldos y salarios
Fin 2
Fuente: Elaboración propia
3.1.3. Diseño del modelado de negocio actual para el control de vacaciones.
 Registro de funcionarios públicos en el sistema de vacaciones.

 Solicitudes de vacación.
100 de 274
Figura 23: Diagrama de modelado de negocio actual de control de vacaciones.
Inicio
Inicio
El
El funcionario
funcionario
público
público cuando
cuando
necesita Los
Los jefes
jefes de
de unidad
unidad
necesita vacación
vacación
se planifican
planifican una
una reunión
reunión
se aproxima
aproxima aa
recoger en
en un
un fecha
fecha
recoger una
una boleta
boleta
del establecida
establecida
del área
área de
de
recursos
recursos humanos
humanos
Los
Los directores
directores de de
Se
Se aproxima
aproxima unidad
unidad en en la
la fecha
fecha
donde
donde la
la acordada
acordada llevan
llevan aa cabo
cabo
encargada
encargada yy estaesta la
la reunión
reunión yy realizan
realizan la la
le
le proporciona
proporciona unauna planificación
planificación de de la
la
la
la boleta
boleta que
que el
el vacación
vacación de de acuerdo
acuerdo aa
funcionario
funcionario llena
llena los
los días
días dede vacación
vacación
con
con sus
sus datos
datos que
que lele corresponde
corresponde aa
personales
personales yy elel cada
cada funcionario
funcionario como
como
tiempo
tiempo de
de establece
establece el el R.I.P.
R.I.P.
vacación
vacación
El
El funcionario
funcionario 11
público
público sese
aproxima
aproxima aa su su jefe
jefe
de
de unidad
unidad yy
entrega
entrega lala boleta
boleta
El
El jefe
jefe de
de unidad
unidad
recepciona
recepciona la la
boleta
boleta yy verifica
verifica si
si
la
la solicitud
solicitud esta
esta dede
acuerdo
acuerdo alal
calendario
calendario
establecido
establecido
El
El jefe
jefe de
de
¿Está
¿Está de
de departamento
departamento
acuerdo
acuerdo aa No identifica
identifica lala para
para la
la
calendario?
calendario? solicitud
solicitud dede días
días de
de
vacación
vacación
Si
El
El jefe
jefe de
de unidad
unidad da da
curso
curso aa los
los días
días dede
vacación
vacación solicitada
solicitada ¿Es
¿Es justificada
justificada la
la
(firma
(firma yy sella
sella la
la solicitud
solicitud de
de No 33
boleta)
boleta) yy descuenta
descuenta vacación?
vacación?
los
los días
días restantes
restantes
Si
El
El funcionario
funcionario al al día
día
siguiente
siguiente no no asiste
asiste aa
la
la institución
institución 22
cumpliendo
cumpliendo con con sus
sus
días
días de de vacación
vacación
101 de 274
22
El
El funcionario
funcionario
cumple
cumple con con sus
sus El
El jefe
jefe de
de unidad
unidad
días
días de de vacación
vacación da
da curso
curso aa la
la
yy retorna
retorna aa su
su vacación
vacación solicita
solicita yy
fuente
fuente de de trabajo
trabajo descuenta
descuenta los los días
días
para
para continuar
continuar restantes
restantes del
del
con
con el
el funcionario
público
cumplimiento
cumplimiento de de
sus
sus obligaciones
obligaciones
33
El
El jefe
jefe de
de
11 Fin
Fin unidad
unidad no no da
da
curso
curso aa loslos días
días
de
de vacación
vacación
solicitados
solicitados por por
el
el funcionario
funcionario
público
público
Al
Al día
día siguiente
siguiente elel
funcionario
funcionario
retorna
retorna aa trabajar
trabajar
al
al área
área que
que le
le
corresponde
corresponde
102 de 274
3.2. DISEÑO DEL MODELO DE NEGOCIO ALTERNATIVO CONSIDERANDO LAS VENTAJAS QUE
OFRECE UN SISTEMA WEB PARA EL PROCESO DE CONTROL DE PERSONAL.
3.2.1. Evaluación de las deficiencias existentes en el proceso actual.
Tabla 3: Identificación de características y deficiencias de los sistemas actuales.
SISTEMAS CARACTERISTICAS DEFICIENCIAS

 Proceso manual.
 Realizado por una persona encargada del registro y  Extravió de documentación.
Proceso de Kardex. almacenamiento de la documentación del kardex del  Informes de personal con
personal. documentación demoran
bastante tiempo en realizarse.
 Sistema de escritorio.  Imprime reportes de vacación

Sistema de control de
 Desarrollo de la aplicación realizada en Visual Basic. para cada funcionario público y
asistencia.
 Sistema conectado con base de datos SQL SERVER. carece de reportes clasificados.
 Sistema de escritorio.  Carece de reportes semanales

Sistema de control de
 Desarrollo de la aplicación realizada en Visual Basic. debido a la falta de integración
vacaciones.
 Sistema conectado con base de datos SQL SERVER. con el dispositivo biométrico.
103 de 274
3.2.2. Diseño del Modelo de negocio alternativo para el proceso de control de personal.
Figura 24: Diagrama de modelado de negocio alternativo del Administrador del sistema.
Administración de usuarios.
Susbsistema de Subsistema de Subsistema de

Administrador Administración de usuarios
kardex asistencia vacaciones
Administrador accede
¿Administración a los servicios del
Inicio
de usuarios?
No sistema y realiza la
solicitud que requiere
El administrador Si
ingresa al sistema
de control de El administrador
personal ¿Usuario realiza la
No
nuevo? búsqueda del
Si funcionario
Si
Ingresa su nombre
de usuario y
contraseña El administrador
¿Modificar
registra al
datos del No
funcionario Busca el servicio Busca el servicio Busca el servicio
usuario?
público solicitado solicitado solicitado
El
¿Usuario y administrador
contraseña Si elimina la
corectos? Ingresa los cuenta de
datos de los usuario.
funcionarios El administrador
No realiza la
modificación de
los datos del
El sistema genera
funcionario
un error y Asigna
muestra al privilegios del
usuario sistema para los
usuarios
El sistema FIn
redirecciona al
usuario a la Recibe el reporte
pagina de inicio de solicitud
del sistema
Fase
104 de 274
Figura 25: Diagrama de modelado de negocio alternativo del Encargado de RR.HH.
Encargado de Recursos Humanos
Subsistema de Dispositivo
Encargado RR:HH. Subsistema de asistencia Subsistema de vacaciones
Kardex biométrico
El encargado Encargado habilita al

registra los datos funcionario para que este
Inicio del funcionario pueda realizar el registro
público de su asistencia
El dispositivo
El encargado biométrico solicita el
ingresa al sistema Si ingreso de el ci del
de control de funcionario y su
personal El encargado huella dactilar
realiza el tickeo de
¿Asistencia
los documentos El encargado realiza
regular?
presentados el registro de los días El subsistema registra El encargado registra
Ingresa su Si de vacación que permiso a cuenta de las huellas dactilares
nombre de No solicita un funcionario vacación del funcionario en el
usuario y público dispositivo biométrico
contraseña Encargado
¿Tiene verifica el
permiso? permiso del
funcionario
Documentación
¿Usuario y ¿Tiene días
completa
contraseña de vacación?
corectos? No
Si ¿acepta no
No
solicitud?
Si
Fin
El sistema Registra los El encargado
genera un error y documentos No no da curso a la
muestra al No presentados en vacación si
usuario el sistema
El subsistema
modifica la
asistencia del
Si Fin
Fin funcionario Si
El sistema
redirecciona al
usuario a la
Indica al funcionario El encargado pide
pagina de inicio
que debe completar al funcionario que
del sistema
documentación le entregue un
faltante justificativo
Seleccionar ¿Solicitud
subsistema justificada? SI
No
Encargado de
Encargado de
RR.HH no da
RR.HH da curso
curso a la
a la vacación
vacación
Fase
105 de 274
Figura 26: Diagrama de modelado de negocio alternativo del Funcionario público.
Funcionario público
Subsistema de Subsistema de Subsistema de Dispositivo

Funcionario público
kardex asistencia vacaciones biométrico
El funcionario ingresa
a la pagina de inicio
del sistema de control
de personal
Ingresa su El dispositivo biométrico

Inicio
nombre de Accede al sistema solicita el ingreso de la
usuario y para solicitar El funcionario huella del funcionario
contraseña servicios por registra el horario para registrar sus
áreas de ingreso a las
ingresos y salidas
8:00 o a las 14:30
No
El sistema
genera un error y
No
muestra al
usuario El funcionario
¿Usuario y ¿Funcionario registra el horario
contraseña si público? de salida a las
corectos? Busca el servicio
12:00 o a las 18;30
solicitado en base
a consultas
Si
El funcionario se
apersona al área de Si
RR.HH y se registra
en el sistema
Busca el servicio
solicitado en Busca el servicio
base a consultas solicitado en base El subsistema verifica
Accede a los a consultas si la huella existe y
servicios del sistema confirma el marcado
y realiza la solicitud de ingreso/salida o
¿Funcionario
requerida para su muestra error
habitilitado?
consulta personal
EL funcionario
accede al modulo de
No permisos y registra
los datos solicitados
El sistema no
reconoce sus
características
físicas
Fin
Recibe el
Fin reporte de la
solicitud
El sistema
redirecciona al
usuario a la pagina
de inicio del sistema
Fase
106 de 274
3.2.3. Selección del modelo de desarrollo de Software.
A continuación se observa la comparación que se realiza entre los diferentes

modelos de desarrollo de software a través de las ventajas y desventajas que estos
tienen para poder identificar y seleccionar el modelo más apropiado para la
elaboración del presente proyecto de desarrollo de software.
Tabla 4: Descripción de las ventajas y desventajas de los modelos de desarrollos de

software.
Modelo Ventajas Desventajas
 Con un paradigma incremental

se reduce el tiempo de
desarrollo inicial, ya que se
implementa la funcionalidad
parcial.
 También provee un impacto
ventajoso frente al cliente, que
 Requiere de mucha
es la entrega temprana de
planeación, tanto
partes operativas del Software.
administrativa como
 El modelo proporciona todas las
Modelo técnica.
ventajas del modelo en cascada
incremental  Requiere de mucha
realimentado, reduciendo sus
planeación, tanto
desventajas sólo al ámbito de
administrativa como
cada incremento.
técnica.
 Permite entregar al cliente un
producto más rápido en
comparación del modelo de
cascada.
 Resulta más sencillo acomodar
cambios al acotar el tamaño de
los incrementos.
107 de 274
Modelo Ventajas Desventajas
 Su uso es libre (como decir

“barra libre”, sin condiciones).
 Define los
Modelo proceso  Hay excelentes textos, que
requerimientos al
unificado explican la aplicación de este
inicio del proyecto.
proceso paso a paso.
 Aseguran la calidad del
desarrollo
 La primera vuelta
de la espiral es el
sistema completo.
 Realiza mejoras
 El análisis del riesgo se hace de
sobre el mismo
forma explícita y clara.
producto a medida
Modelo de espiral  Reduce riesgos del proyecto que avanza el
 Incorpora objetivos de calidad desarrollo del
 Integra el desarrollo con el proyecto.
mantenimiento, etc.  Requiere
experiencia en la
identificación de
riesgos.
El proceso unificado posee una gran desventaja para este proyecto, porque según el
análisis que se realizó en la tabla comparativa define los requerimientos del sistema
al inicio del proyecto y en el presente proyecto no se tienen todos los requerimientos
desde el inicio sino que a medida de que el desarrollo del software avance la
institución añadirá nuevos requerimientos al sistema.
El modelo incremental se basa en la entrega del producto total en el primer

incremento del proyecto y a medida que este avanza realiza mejores en este
108 de 274
producto, la institución para la cual se desarrollara el sistema cuenta con diferentes
tipos de personal, el mismo que no se sentirá a gusto con el sistema, si es que se le
presenta un sistema pero que no ofrezca las comodidades necesarias al usuario.
Luego de identificar y analizar las ventajas y desventajas que ofrecen los diferentes
modelos de desarrollo de software seleccionados se llegó a la conclusión que para la
elaboración del presente proyecto se utilizara el modelo de desarrollo incremental
debido a que tiene más flexibilidad en los requerimientos que se realizan a medida
que avanza el proyecto.
Además se debe tener en cuenta que debido a que el proyecto se desarrollará para
una institución pública es de vital importancia entregar pequeños incrementos
funcionales para la institución, para que pueda ser implementado dentro de la misma.
Al presentar estos incrementos la institución comprobara las funcionalidades del

producto y añadirá nuevas funcionalidades de acuerdo a la necesidad y a la
conveniencia de la institución.
3.2.4. Plan de incrementos para el desarrollo del software.
PRIMER INCREMENTO
Desarrollo del subsistema de administración de kardex basado en componentes de la

SEGUNDO INCREMENTO
Diseño e implementación del subsistema de control de asistencia, con el módulo de

asignación de horarios de ingreso y salidas del personal integrado con el subsistema
TERCER INCREMENTO
Desarrollo del subsistema de vacaciones integrado con el subsistema de control de

asistencia.
109 de 274
CUARTO INCREMENTO
Integración del sistema basado en Arquitectura Orientada a Servicios con dispositivo

de control biométrico.
QUINTO INCREMENTO
Implementación de mecanismos para la generación y exportación de reportes de

verificación de control de kardex, asistencia y vacaciones.
3.3. DESARROLLO DEL SUBSISTEMA DE ADMINISTRACIÓN DE

KARDEX BASADO EN COMPONENTES DE LA
ARQUITECTURA ORIENTADA A SERVICIOS.
3.3.1. Análisis.
Requerimientos Funcionales.
 El sistema debe permitir registrar la información de nuevos usuarios en la

base de datos.
 El sistema debe permitir buscar a un usuario para poder modificar o eliminar
sus datos del sistema.
 El sistema debe permitir asignar un cargo a un funcionario.
 El sistema debe permitir registrar los datos de un nuevo kardex de un
funcionario público.
 El sistema debe poder realizar la búsqueda del kardex de un funcionario
público para poder modificar o eliminar los datos del mismo.
 El subsistema de control de kardex debe poder acceder a los servicios
otorgados por la institución.
 El sistema debe permitir realizar el control de la documentación del kardex de
un funcionario público para poder modificar o eliminar los datos del mismo.
 El subsistema debe permitir que un funcionario cree su cuenta en caso de que
haya entregado su kardex.
110 de 274
Requerimientos no funcionales.
 Compatibilidad
El sistema debe visualizarse y funcionar correctamente en cualquier
navegador, especialmente en Internet Explorer, Google Chrome y Mozilla
Firefox.
 Disponibilidad
El sistema debe estar disponible para su uso las 24 horas para que cualquier
usuario pueda hacer uso del mismo.
 Extensibilidad
Debido a que el sistema está diseñado bajo la Arquitectura Orientada a
Servicios puede integrarse de manera fácil con los diferentes sistemas de la
institución.
 Mantenibilidad
Se puede agregar nuevos requerimientos al proyecto de software debido a
que utiliza el modelo incremental y la Arquitectura Orientada a Servicios.
 Seguridad
Para poder acceder al sistema de control de personal se necesita estar
registrado en el sistema, el único con la facultad de realizar el registro de
usuarios es el administrador del sistema.
 Usabilidad
El sistema está diseñado de manera amigable para el usuario que no necesita
conocimientos avanzados para poder hacer uso de los servicios que este
ofrece.
Identificación de actores
Se ha identificado los siguientes actores: Administrador de Sistemas, Encargado de

RR.HH y funcionario público que serán representados en los diagramas de casos de
uso como se muestra a continuación:
111 de 274
Figura 27: Actores del primer incremento.
uc actores
Administrador de Encargado de
Sistemas RR.HH.
Descripción de actores
Se describen las funciones de los actores a continuación:
Para el primer incremento se tienen dos actores, el administrador de sistemas y el

encargado de recursos humanos, cuyas funciones en el sistema se detallan a
continuación.
 Administrador de sistemas.
Este usuario es una persona de la unidad de sistemas y tiene amplio
conocimiento sobre manejo de sistemas y servidores, usualmente es una
persona del área de sistemas, se encargara de administrar las cuentas de
usuario del sistema SISKAV, este usuario es el único que puede realizar la
asignación de privilegios a los usuarios del sistema, así mismo puede generar
todo tipo de reportes de acuerdo a sus necesidades.
 Encargado de RR.HH.
Es aquel usuario del sistema que puede realizar el registro del kardex de un
funcionario público de la institución y realizar modificaciones o eliminaciones
de los kardex del sistema, así mismo puede generar reportes de los
subsistemas que están a su cargo.
112 de 274
Diagrama de casos de uso del sistema.
A continuación en la siguiente figura se detalla mediante un diagrama los casos de

uso del sistema para el primer incremento, donde participan dos actores que
interactuarán con el sistema, el primero que es el administrador de sistemas, se
encargara de la administración de usuarios del sistema, el segundo el encargado de
recursos humanos, este usuario es aquel que se encarga del control del kardex de la
institución y cuenta con las siguientes funcionalidades dentro del sistema las cuales
se mencionan a continuación: Administrar datos del personal, Administrar
documentación y finalmente la administración de los cargos respectivos.
Figura 28: Casos de uso del sistema del primer incremento.
uc Casos de uso del sistema
Ingresar al sistema
Administrador de
Administrar usuarios
Sistemas
Administrar datos del

personal
Encargado de
RR.HH.
Administrar
documentacion
Administrar cargo
113 de 274
Descripción de los casos de uso del sistema.
Tabla 5: Documentación del caso de uso ingresar al sistema.
CU-1 INGRESAR AL SISTEMA
Haber registrado sus datos y presentado la documentación al

encargado para ser registrado en el subsistema de kardex y además
Precondición
haber creado su cuenta o haber solicitado al administrador una
cuenta.
El usuario debe ingresar su nombre de usuario y contraseña para

Descripción poder acceder a las funcionalidades que otorga el sistema de
acuerdo al privilegio asignado.
Actor Administrador de sistemas y Encargado.
PASO ACCION
1 El usuario ingresa a la página principal del sistema.
Ingresa su nombre de usuario, contraseña y presiona el

2
botón de ingreso.
Secuencia normal El sistema llama a la clase login y verifica si los datos

3
ingresados son los correctos.
El redireccionador del sistema evalúa el grado de privilegio

4
que tiene el usuario y lo redirecciona.
El sistema muestra al usuario las funcionalidades de

5
acuerdo a su privilegio.
El usuario puede acceder a cualquier funcionalidad del sistema de

Post condición
114 de 274
CU-1 INGRESAR AL SISTEMA
PASO ACCION
Si los campos están vacíos retorna mensaje: Los campos

1
marcados con * son obligatorios.
Excepciones Si el usuario o contraseña son inválidos devuelve mensaje:

2
Usuario o contraseña incorrectos.
Si ingresa “” el sistema los convierte en cadenas vacías y

3 devuelve mensaje: Los campos marcados con * son
obligatorios.
Al sistema de control de personal solo pueden acceder el personal

Comentarios perteneciente a la institución: GOBIERNO MUNIIPAL AUTONOMO
DE COCHABAMBA.
Tabla 6: Documentación del caso de uso administrar usuarios.
CU-2 ADMINISTRAR USUARIOS
Haber presentado la documentación al encargado para ser

Precondición
registrado en el subsistema de kardex.
El administrador ingresa al sistema para poder acceder a las

Descripción funcionalidades que otorga, las cuales son: Registrar usuarios,
buscar usuarios, modificar usuarios y eliminar usuarios.
Actor Administrador de sistemas.
115 de 274
CU-2 ADMINISTRAR USUARIOS
PASO ACCION
El sistema redirecciona a la página de usuarios con las

1 funcionalidades para el administrador que son: registrar
usuarios y administrar usuarios.
El usuario elige una de las funcionalidades haciendo click

2
en el botón.
Secuencia normal
El administrador registra los datos del usuario para que
3
este pueda acceder al sistema.
El administrador ingresa el número de ci del funcionario

4
para procesar la búsqueda.
El usuario obtiene los datos de la búsqueda y puede

5
modificar los datos o eliminarlos.

Post condición
PASO ACCION

1
Excepciones
Si no existe la documentación del funcionario el sistema
2 devuelve mensaje de error, “El kardex del funcionario no
existe”.
Si no existe la cuenta del funcionario el sistema devuelve

3
mensaje, “el usuario no existe”.
La asignación de privilegios de las cuentas de usuarios solo la puede

Comentarios
realizar el administrador de sistemas.
116 de 274
Tabla 7: Documentación del caso de uso administrar datos del personal.
CU-3 ADMINISTRAR DATOS DEL PERSONAL
Precondición Ninguna.
El encargado ingresa al sistema para poder acceder a las

funcionalidades que otorga, las cuales son: Registrar datos del
Descripción
personal, buscar datos del personal, modificar datos del personal y
eliminar datos del personal.
Actor Encargado de RR.HH.
PASO ACCION
El sistema redirecciona a la página de administración de

datos del personal con las funcionalidades para el
1
administrador que son: registrar y administrar datos del
personal.
Secuencia normal El usuario elige una de las funcionalidades haciendo click

2
en el botón.
El administrador registra los datos personales del

3
funcionario y registra la documentación.

4
para procesar la búsqueda.
117 de 274
CU-3 ADMINISTRAR DATOS DEL PERSONAL

5

Post condición
PASO ACCION
1 marcados con * son obligatorios.
Excepciones
Si no existen los datos del funcionario el sistema devuelve

2 mensaje de error, “El kardex del funcionario no existe”.
El registro de datos personales es atribución exclusiva del encargado

Comentarios
de RR.HH.
Tabla 8: Documentación del caso de uso administrar documentación.
CU-4 ADMINISTRAR DOCUMENTACIÓN
Precondición Haber registrado los datos del usuario en el sistema.
118 de 274

funcionalidades que otorga, las cuales son: Registrar
Descripción
documentación, buscar documentación, modificar documentación y
eliminar documentación.
PASO ACCION

datos del personal con las funcionalidades para el
1 administrador que son: registrar y administrar
documentación.

2 en el botón.
Secuencia normal
El encargado registra la documentación del funcionario.

3

4 para procesar la búsqueda.
119 de 274

5 modificar los datos o eliminarlos.

Post condición
PASO ACCION
Excepciones
1
mensaje de error, “El kardex del funcionario no existe”.
El registro de documentación es atribución exclusiva del encargado

Comentarios
de RR.HH.
Tabla 9: Documentación del caso de uso administrar cargo.
CU-5 ADMINISTRAR CARGO
Haber registrado los datos personales del funcionario y su

Precondición
documentación respectiva.

Descripción funcionalidades que otorga, las cuales son: Registrar cargo, buscar
cargo.
120 de 274
CU-5 ADMINISTRAR CARGO
PASO ACCION

1 datos de cargo con las funcionalidades para el
administrador que son: registrar y administrar cargo.

Secuencia normal 2
en el botón.
3 El encargado registra el cargo del funcionario público.
El encargado ingresa el número de ci del funcionario para

4
procesar la búsqueda y obtiene los datos de la búsqueda.

Post condición
PASO ACCION

1
Excepciones marcados con * son obligatorios.

2
Comentarios El registro de cargo es atribución exclusiva del encargado de RR.HH.
121 de 274
Diagramas de casos de uso por actor.
Figura 29: Diagrama de caso de uso administrador del sistema.
uc Casos de uso por actor
Ingresar al sistema
Crear nuev a usuario
Administrador de
«include»
sistemas
Modificar usuarios
Administrar usuarios
«extend»
«include»
Buscar usuarios
«extend»
Eliminar usuarios
Actor: Encargado de RR.HH.
Caso de Uso: administrar datos del personal, administrar documentación y

administrar.
Descripción: Se encarga de realizar el registro del kardex de los funcionarios

públicos y de la asignación de los cargos.
122 de 274
Figura 30: Diagrama casos de uso encargado RR.HH.
uc Casos de uso por actor
Ingresar al sistema
Registrar datos del

personal
Administrar datos del «include» Modificar datos de

personal personal
«include» «extend»
Buscar datos del
personal
«extend» Eliminar datos de
personal
Registrar
documentacion
Encargado RR.HH. Administrar «include»
documentacion Modificar
documentacion
«include» Buscar «extend»
documentacion
«extend»
Eliminar
documentacion
Registrar cargo
«include»
Administrar cargo
«include»
Buscar cargo
3.3.2. Diseño.
Diagramas de Colaboración.
Caso de uso: Ingresar al sistema
Figura 31: Diagrama de colaboración ingresar al sistema.

sd comunicacion colaboracion
1: Enviar datos de usuario() 1.1: Buscar usuario()
1.3: mensaje de error o habilita funciones del sistema()

IU INGRESAR AL 1.2: metodo devuelve valor()
GESTOR USUARIOS USUARIOS
SISTEMA
123 de 274
Caso de uso: Administrar usuarios.
Figura 32: Diagrama de colaboración administrar usuarios.

2.3: Procesar busqueda()
2.4: Enviar datos()

PERSONAL
GESTOR PERSONAL
2.2: Buscar datos()

2.5: Enviar datos personales()
2: Enviar datos() 2.1: Enviar datos de usuario() 2.6: Procesar usuario()
2.8: usuario registrado() 2.7: servicio devuelve valor de registro()

IU ADMINISTRAR IU REGISTRAR GESTOR USUARIOS USUARIOS
USUARIOS NUEVOS USUARIOS
2.11: Mensaje de error o Datos del usuario()

2.9: Enviar datos()
2.10: Enviar datos de usuario para busqueda()
IU
BUSCAR/MODIFICAR/ELIMINAR
USUARIOS
Caso de uso: Administrar datos del personal.
Figura 33: Diagrama de colaboración administrar datos del personal.

3: Enviar datos()
3.1: Enviar datos personal() 3.2: Procesar datos personal()
3.4: Datos registrados() 3.3: Servicio devuelve valor de registro()

IU ADMINISTRAR PERSONAL
DATOS DEL IU REGISTRAR GESTOR PERSONAL
PERSONAL NUEVOS DATOS
3.7: Mensaje de error o datos del funcionario()
3.5: Enviar datos()
3.6: Enviar datos de personal para busqueda()
IU
DATOS PERSONAL
124 de 274
Caso de uso: Administrar Documentación
Figura 34: Diagrama de colaboración administrar documentación.

4.4: Enviar datos()

PERSONAL
GESTOR PERSONAL
4.5: Enviar datos de personal() 4.2: buscar datos personal()
4: Enviar datos() 4.1: Enviar datos documentacion() 4.6: Procesar datos documentacion()
4.8: Documentacion registrada() 4.7: Servicio devuelve valor de registro()
IU ADMINISTRAR IU REGISTRAR GESTOR
DOCUMENTACION
DOCUMENTACION DOCUMENTACION DOCUMENTACION
4.11: Mensaje de error o datos de documentacion()

4.9: Enviar datos() 4.10: Enviar dato de documentacion para busqueda()
IU
DOCUMENTACION
Caso de uso: Administrar cargo.
Figura 35: Diagrama de colaboración administrar cargo.

5.4: Enviar datos()

GESTOR PERSONAL PERSONAL
5.5: Enviar datos de personal() 5.2: buscar datos personal()
5: Enviar datos() 5.1: Enviar datos de cargo() 5.6: procesar datos de cargo()
5.8: Cargo registrado() 5.7: Servicio devuelve valor de registro()

IU ADMINISTRAR GESTOR CARGO CARGO
IU REGISTRAR
CARGO
CARGO
5.11: Mensaje de error o datos de cargo()
5.10: Enviar dato de cargo para busqueda()

5.9: Enviar datos()
IU BUSCAR
125 de 274
Diagrama de clases.
El diagrama de clases para el primer incremento incluye cuatro clases que se

detallan a continuación en la siguiente figura.
Figura 36: Diagrama de clases del primer incremento.
126 de 274
3.3.2.1. Selección del lenguaje de programación, Framework e IDE.
En la siguiente tabla que se muestra a continuación se realizara la identificación y

selección de lenguaje de programación que se utilizara en el desarrollo del presente
proyecto de grado considerando las ventajas y desventajas de los lenguajes elegidos
para la correspondiente selección.
Tabla 10: Descripción de las ventajas y desventajas de los lenguajes de

programación.
LENGUAJE VENTAJAS DESVENTAJAS
 Uso del Framework

.NET de Microsoft.
Esto significa que es
mucho más difícil de
 Lenguaje orientado a objetos, transferir su
Multiplataforma a nivel binario y programa de
código fuente. Windows a otro
 En C# o cualquier lenguaje .NET se sistema operativo.
C# con obtiene un binario .exe Sin embargo, la
asp.net  Los programas .NET corren sobre el llegada del Proyecto
FrameWork .NET Mono ha hecho está
 El framework .NET corre cualquier mucho más fácil de
programa creado en cualquier lo que era antes,
lenguaje que genere codigo .NET ahora se puede
 Ambiente de desarrollo muy rápido. portar casi cualquier
programa en C # que
desea tanto Linux y
Mac OS.
127 de 274
 PHP funciona sobre prácticamente

todas las plataformas imaginables y
garantiza una alta velocidad de
ejecución, además de una excelente  El desarrollo en php
estabilidad. se realiza de manera
 Su seguridad se ve reforzada por el lenta y se necesita
PHP conocimiento
hecho de que el código original
permanece oculto al usuario: el avanzado en
navegador lo ejecuta y lo muestra programación.
“traducido” a HTML.
 A diferencia de otros lenguajes
(como ASP, de Microsoft) es
gratuito y open source
 Lenguaje orientado a objetos,

 Multiplataforma a nivel binario y
código fuente, siempre y cuando el
OS anfitrión tenga las mismas  La portabilidad de
clases. java hace que la
Java  En Java al compilar una clase se ejecución de las
obtiene un archivo binario .class aplicaciones sea
 Java corre sobre un framework muy lenta.
denominado, La máquina virtual de
JAVA
 Pero el framework de Java solo
corre programas JAVA
128 de 274
Después de realizar el análisis de las distintas ventajas y desventajas que ofrecen los
distintos lenguajes de programación modernos se llegó a la conclusión de que para
desarrolla el siguiente software se hará uso del lenguaje de programación c#, con el
framework .NET y el IDE Visual Studio.
Se eligió C# con asp por que el rendimiento es mucho mejor frente a los otros
lenguajes, además porque este lenguaje ha sido creado para que su aprendizaje sea
sencillo brindando recursos y herramientas al desarrollador para facilitarle el trabajo
al momento de la identificación de errores y generación de código.
C# trabaja en un entorno muy rápido y fácil de manejar utilizando el IDE Visual

Studio que brinda las facilidades necesarias al desarrollador al momento de trabajar
en la elaboración de un proyecto.
Otro punto importante que se llegó a identificar es que el framework .net es de fácil
aprendizaje y no requiere conocimientos avanzados por el contrario en php tienes
que realizar todo desde cero, aunque actualmente están apareciendo nuevos
frameworks para php que facilitan la generación de código pero son muy difíciles de
aprender.
En la comparación que se realizó entre C# y Java se identificó que son leguajes con
características muy similares.
Pero la ventaja de C# frente a Java no radica en el lenguaje de programación sino en

el framework y en el IDE que estos utilizan para elaborar un proyecto.
3.3.2.2. Selección del Sistema de gestión de Base de datos.
Para realizar la selección del sistema de gestión de base de datos se realizara la

siguiente tabla comparativa donde se identifican las ventajas y desventajas de los
SGDB seleccionados.
129 de 274
Tabla 11: Descripción de las ventajas y desventajas de los sistemas de gestión de
base de datos.
 Llega a alguna de las cargas de trabajo

más grandes del mundo, dando prueba
de ello los sólidos resultados de la
referencia de la normas de la industria.
 Ayuda los clientes a obtener mayor
conocimiento del negocio y tomar  SQL Server
decisiones más rápidas gracias a la sólo funciona
buena integración del producto con la en la
interfaz de usuario ya conocida del plataforma
Sistema Microsoft Office. Por ejemplo, Windows, una
SQL Server complementos tales como data mining de las
para Excel utilizan SQL Server y Microsoft principales
Office para ofrecer análisis de los datos limitaciones
del cliente. para que sea
 Microsoft SQL Server es más barato una solución
comprar. empresarial.
 Microsoft SQL Server tiene la parte
superior de rendimiento TPC-C y los
resultados de precio / rendimiento.
 Microsoft SQL Server es generalmente
aceptado como más fácil de instalar, usar
y administrar.
130 de 274
 Oracle es el motor de base de datos

objeto-relacional más usado a nivel
mundial.
 Puede ejecutarse en todas las
plataformas, desde una Pc hasta un
supercomputador.
 Oracle está disponible en múltiples
plataformas como Windows, todos los
 Costo de
sabores de Unix de proveedores como
Oracle mantenimiento
IBM, Sun, Digital, HP, Sequent, etc. La
elevado.
naturaleza multi-plataforma de Oracle
hace que sea una verdadera solución
empresarial
 Existe una versión personal para
Windows 9x, lo cual es un punto a favor
para los desarrolladores que se llevan
trabajo a casa.
 Oracle es la base de datos con más
orientación hacía INTERNET.
 MySQL software es Open Source

 Velocidad al realizar las operaciones, lo
que le hace uno de los gestores con  Una de las
mejor rendimiento. principales es
MySQL
 Bajo costo en requerimientos para la la seguridad
elaboración de bases de datos, ya que otorga.
que debido a su bajo consumo puede
ser ejecutado en una máquina con
escasos recursos sin ningún problema.
131 de 274
Aunque no es cierto que Oracle sea mejor que SQL Server o viceversa Ambos
productos pueden ser utilizados para construir un sistema estable y eficiente y la
estabilidad y la eficacia de sus aplicaciones y bases de datos dependerá más bien de
la experiencia de los desarrolladores de bases de datos y administrador de base de
datos del proveedor de la base de datos.
Por otro lado realizando las comparaciones entre Oracle y MySQL se identificó que
una de las principales ventajas de MySQL sobre Oracle es que MySQL es gratuito y
que una de las principales ventajas de Oracle sobre MySQL es la seguridad que este
brinda, además de esta se identificaron las siguientes ventajas:
 Oracle es el motor de base de datos objeto-relacional más usado a nivel mun-

dial.
 Puede ejecutarse en todas las plataformas, desde una Pc hasta un super-
computador.
 Oracle está disponible en múltiples plataformas como Windows, todos los sa-
bores de Unix de proveedores como IBM, Sun, Digital, HP, Sequent, etc. La
naturaleza multi-plataforma de Oracle hace que sea una verdadera solución
empresarial
 Existe una versión personal para Windows 9x, lo cual es un punto a favor para
los desarrolladores que se llevan trabajo a casa.
 Oracle es la base de datos con más orientación hacía INTERNET.
Por tal motivo y como una de las principales necesidades es la seguridad de los
datos dentro de la institución, debido a que el sistema trabajara con datos de vital
importancia, es que, para el presente proyecto se empleara el Sistema de gestión de
base de datos Oracle.
Además de esto la institución cuenta con la licencia de servidor para Oracle, por
tanto facilita la instalación de la base de datos para la implementación del sistema de
control de personal.
132 de 274
Diseño de la Base de datos.
Figura 37: Diseño de la base de datos utilizando Oracle data modeler.
Diccionario de datos.
Tabla 12: Diccionario de datos de la tabla usuarios.
USUARIOS
Nombre del
Tipo Descripción
Campo
Auto incrementable que empieza en 1, clave primaria, no

Iduser(PK) Int
admite nulos.
133 de 274
USUARIOS
Nomuser Varchar2 Nombre de usuario del funcionario público.
Contras Varchar2 Contraseña del funcionario público.
Privileg Varchar2 Privilegio del funcionario público en el sistema.
Fechcrea Date Fecha de creación de la cuenta de usuario.
Email Varchar2 Dirección de correo electrónico del funcionario público.
CIPERS(FK) Int Llave foránea que señala a la tabla personal.
Tabla 13: Diccionario de datos de la tabla personal.
PERSONAL
Nombre del
Tipo Descripción
Campo

CIPERS(PK) Int
admite nulos
Nombre Varchar2 Nombre del funcionario público.
Appat Varchar2 Apellido paterno del funcionario público.
134 de 274
PERSONAL
Apellido materno del funcionario público perteneciente a la

Apmat Varchar2
institución.
Apellido del esposo de la funcionario público, a partir de esto

Apesp Varchar2
se facilita la identificación del género de la persona.
Fechnac Date Fecha de nacimiento del individuo.
Lugnac Varchar2 Población o provincia de origen.
Depto Varchar2 Departamento donde nació la persona.
Domic Varchar2 Ubicación del domicilio
Ntelf Int Número de teléfono.
Nlibmil Varchar2 Número de la libreta militar
Grupsang Varchar2 Grupo sanguíneo al que pertenece.
Máximo grado de instrucción académica alcanzado donde se

Gradoinst Varchar2 registrará el mayor grado de instrucción alcanzado por el
funcionario.
Profesión Varchar2 Profesión del individuo.
Fechainst Date Fecha de ingreso a la institución.

135 de 274
Tabla 14: Diccionario de datos de la tabla documentación.
DOCUMENTACION
Nombre del
Tipo Descripción
Campo

IDDOC(PK) Int
admite nulos
Fotografia Varchar2 Verificación de fotografía.
Formincom Varchar2 Verificación del formulario de incompatibilidad.
Croqdom Varchar2 Verificación de croquis de domicilio.
Fotocopci Varchar2 Verificación de la fotocopia de carnet de identidad.
Currivit Varchar2 Verificación del curriculum vitae.
Titprovnac Varchar2 Verificación del título en provisión nacional.
Declajur Varchar2 Verificación de la declaración jurada.
Certifnac Varchar2 Verificación del certificado de nacimiento.
Certifmat Varchar2 Verificación de certificado de matrimonio.
Certifnacdep Varchar2 Verificación del certificado de nacidos dependientes.
136 de 274
DOCUMENTACION
Segusal Varchar2 Verificación del seguro de salud.
Afpnua Varchar2 Verificación del formulario afpnua.
Fechadoc Varchar2 Fecha en la cual se registró la documentación.
Tabla 15: Diccionario de datos de la tabla cargo.
CARGO
Nombre del
Tipo Descripción
Campo

Idcargo(PK) Int
admite nulos
Fechacargo Date Fecha de asignación de cargo en la institución.
Numero de memorándum asignado para la designación del

Nummemo Int
cargo.
Forma Varchar2 Forma de asignación del cargo del funcionario.
Cargo Varchar2 Cargo que se asigna al funcionario.

137 de 274
Diseño de la Arquitectura Orientada a Servicios.
Figura 38: Componentes de la Arquitectura Orientada a Servicios.
En la sección de código se explica la gráfica anterior donde se describe la

arquitectura orientada a servicios con sus diferentes utilizados (WSDL, XML, SOAP,
UDDI), con la utilización de los protocolos se permitirá la interconexión de los
subsistemas del sistema de control personal a través de la los servicios web que
serán diseñados para interactuar con la base de datos (Servicio de kardex, servicio
de asistencia, servicio de vacaciones, servicio biométrico).
En la figura que se muestra a continuación se describe la arquitectura orientada a

servicios para el subsistema de asistencia, en el cual se puede observar la
interconexión existente entre los diferentes módulos con la base de datos y con las
aplicaciones.
138 de 274
Figura 39: Aplicación de la arquitectura orienta a servicios en el subsistema de
control de asistencia.
Aplicaciones pertenecientes
al subsistema de asistencia.
Aplicación Registro Aplicación Verifi-

de huellas car huellas
Servicio que permite

acceder a la base datos Servicio
para obtener métodos. biométrico
Web Method Web Method

(Registrar (Verificar asis-
asistencia) tencia)
Base de datos del

Sistema de
de control
personal. BDCONTROL
139 de 274
3.3.3. Código.
Según las herramientas y lenguaje de programación seleccionado para la

implementación del presente proyecto se utilizaran como herramientas (MS Visual
Studio 2010 y C#.NET) en base a la Arquitectura Orientada a Servicios (SOA), para
aplicar la arquitectura orientada a servicios se hará uso de los servicios web de
asp.NET, que están disponibles en la versión 3.5 del framework de asp.NET.
El gobierno municipal autónomo de Cochabamba es una institución que está en

crecimiento, por lo tanto se propuso que por cada caso de uso se creara un servicio
en la SOA del sistema, esto es favorable para la institución y para el sistema, porque
cualquier cambio que pueda existir en la institución pueda ser cambiado solo el caso
de uso afectado y por consecuencia su servicio. Esto reduciría considerablemente en
cuanto a tiempo los cambios o incrementos que pueden suceder en el futuro.
Por tanto en primer lugar se define cuáles son los servicios a implementar:
 Servicio de control de kardex.

 Servicio de control de asistencia.
 Servicio de vacaciones
 Servicio de reportes Administrador.
 Servicio de reportes de Encargado.
 Servicio de reportes de Funcionario.
 Servicio biométrico.
Para el desarrollo de la arquitectura orientada a servicios y la creación de servicios,

se siguió el siguiente proceso que se describe a continuación, para lo cual se tienen
los siguientes requisitos.
 Servidor de IIS (versión o igual superior a 7.0).

 Servicios UDDI.
 Base de datos Oracle (versión superior a 10g).
 Visual Studio 2010 y Framework asp.NET 3.5.
140 de 274
Creación de un servicio web.
Para crear un servicio, se ingresa a visual studio y se crea un nuevo servicio web de
asp.net y se almacena el servicio en el servidor IIS. Se agrega un servicio web de
asp.net como se muestra en la siguiente impresión de pantalla, el mismo que ya
viene con configuraciones preestablecidas para reducir el grado de dificultad al
momento de crear los servicios necesarios.
Figura 40: Creación de un servicio web.
Servicio web ASP.NET.
Al crear un servicio web ASP. NET este ya viene con configuraciones

preestablecidas como ser: binding, la dirección de la descripción del servicio WSDL.
Además de forma automática crea un web method “Hello World” como ejemplo para
crear los contratos que tendrá el servicio dentro de la clase.
141 de 274
Figura 41: Configuraciones y WebMethod por defecto.
Creación de métodos del Servicio Ingreso sistema.
Para crear un método dentro del servicio se utiliza [Webmethod] y se crea el

procedimiento, este código se realiza dentro del servicio, en este caso por ejemplo el
Servicio web de kardex como se muestra en la siguiente figura.
Figura 42: Contratos del servicio web.
142 de 274
Verificación de operaciones en el Servicio Web Kardex.
Para asegurarnos que se realizó la conexión correcta con la base de datos es

recomendable probar el servicio creado, para ello realizamos la invocación del
servicio mediante el explorador.
Figura 43: Verificación del servicio web.
Invocación de servicio web a aplicación externa.
Para hacer la invocación a los servicios y a sus operaciones se debe adicionar una
nueva referencia web para ello realizamos la búsqueda del servicio en el servidor
uddi a través del proveedor de servicios en este caso el proveedor lleva el
denominativo de Gobierno Municipal Autónomo de Cochabamba (usualmente en el
nombre de proveedor se escribe el nombre de la empresa o institucion) , obtenemos
la uri del servicio web, para ello se añade una referencia de servicio y se escribe la
dirección del servidor uddi posteriormente se busca el servicio y se lo añade como
referencia web.
143 de 274
Figura 44: Agregar referencia del servicio web.
Invocación de servicios.
Para invocar el servicio se instancia una clase para que esta llame al método del
servicio. A continuación se muestra la instancia de la clase.
Figura 45: Instancia del servicio web en un aplicación
144 de 274
Implementación del sistema.
Terminado el diseño del sistema se continúa con la implementación, gran parte de la

arquitectura del sistema se captura durante el diseño del sistema. Pese a esto toda
la arquitectura sigue el enfoque del Modelo Incremental.
Desarrollo de interfaz de usuario
Según los requerimientos de los usuarios y sus necesidades podemos hacer el

desarrollo de la interfaz de inicio del sistema donde se muestra la arquitectura
Orientada a Servicios (SOA).
Implementación de interfaces.
 Interfaz principal
Interfaz principal donde se muestra el inicio del sistema.
Figura 46: Interfaz de bienvenida del sistema.
145 de 274
 Interfaz de Registro de usuarios.
En la siguiente figura se aprecia el formulario de registro de usuarios.
Figura 47: Interfaz de registro de usuarios.
 Interfaz de Administración de usuarios.
En la siguiente figura se muestra el formulario de administración de usuarios

donde se pueden realizar modificaciones de datos y eliminaciones.
Figura 48: Administración de usuarios.
146 de 274
 Interfaz de Registro de kardex.
A continuación se muestra el formulario de registro de datos personales.
Figura 49: Registro de datos del personal.
 Interfaz de registro de documentación.
A continuación se muestra el formulario de registro de datos personales.
Figura 50: Administración de documentación.
147 de 274
3.3.4. Pruebas.
En esta etapa se realiza pruebas de funcionalidad por casos de uso, tomando el caso
del administrador del sistema y el Encargado de RR.HH. de la aplicación web como
tal, de los cuales, se puede destacar que:
El desarrollo de la aplicación web basada en Arquitectura Orientada a Servicios para

el primer incremento permite responder al objetivo planteado, el cual, sirve para
realizar el registro de usuarios y registro del kardex de un funcionario.
Caso de uso: Ingresar al Sistema
El administrador ingresa al sistema con datos de usuario y contraseña, luego, se

procede a la verificación del usuario en la base de datos de usuarios, controlando
sus privilegios para el acceso al sistema.
Tabla 16: Pruebas para el caso de uso ingresar al sistema.
CASO DE USO DESCRIPCION RESULTADO
Ingreso de
Habilita opciones del
contraseña y usuario
sistema.
correctos.
Ingreso de usuario y
Ingresar al sistema contraseña Mensaje de error.
incorrectos.
Mensaje de error los

Ingreso de campos
campos marcados
vacíos.
en * son obligatorios.
148 de 274
Ingreso de números
Mensaje de error tipo
donde corresponde
de dato incorrecto.
letras.
Ingreso de letras
Mensaje de error tipo
donde corresponden
de dato incorrecto.
números.
Caso de uso: Administrar Usuarios
El administrador ingresará los datos de usuario y contraseña para asignar a una

cuenta a un determinado usuario.
Tabla 17: Pruebas para el caso de uso administrar usuarios.
Ingreso de datos correctos en

Usuario registrado.
el formulario de registro.
Datos del usuario y

Ingreso de nombre de usuario
habilita funciones de
Administrar correcto en el formulario de
modificación y
usuarios búsqueda.
eliminación.
Mensaje de error el
Ingreso de nombre de usuario
nombre de usuario
incorrecto
no existe.
149 de 274
Ingreso de número de ci no Mensaje de error, el

existente. kardex no existe.

Ingreso de campos vacíos. campos en * son
obligatorios.
Ingreso de números donde Mensaje de error tipo

corresponde letras. de dato incorrecto.
Ingreso de letras donde Mensaje de error tipo

corresponden números. de dato incorrecto.
El encargado de RR.HH. se encargará de crear o registrar en la base de datos, un

kardex nuevo, también, podrá buscar kardex ya registrados para modificar las
características o eliminar los datos del mismo.
Tabla 18: Pruebas para el caso de uso administrar datos del personal.
Datos del personal

Administrar datos Ingreso de datos correctos en registrado y habilita
del personal el formulario de registro. control de
documentación.
150 de 274
Datos del funcionario

Ingreso de ci correcto en el y habilita funciones
formulario de búsqueda. de modificación y
eliminación.

Ingreso de ci incorrecto. datos del funcionario
no existen.

obligatorios.
Ingreso de números donde Mensaje de error tipo

corresponde letras. de dato incorrecto.
Ingreso de letras donde Mensaje de error tipo

corresponden números. de dato incorrecto.
Caso de uso: Administrar documentación.
El encargado de RR.HH. se encargará de crear o registrar en la base de datos, el

control de documentación respectivo, también, podrá verificar si se presentó toda la
documentación para posteriormente modificar o eliminar los datos.
151 de 274
Tabla 19: Pruebas para el caso de uso administrar documentación.
Ingreso de datos
correctos en el Documentación registrada.
formulario de registro.
Ingreso de ci correcto en Datos del funcionario y habilita

el formulario de funciones de modificación y
búsqueda. eliminación.
Administrar
documentación
Mensaje de error la
Ingreso de ci incorrecto. documentación del funcionario
no existe.
Ingreso de campos Mensaje de error los campos

vacíos. en * son obligatorios.
Caso de uso: Administrar cargo.
El encargado de RR.HH. se encargará de registrar en la base de datos, la

asignación de un nuevo cargo, también, podrá buscar cargos ya asignado a los
funcionarios.
152 de 274
Tabla 20: Pruebas para el caso de uso administrar cargo.
En la siguiente tabla se muestran las pruebas de funcionalidades que se realizaron

para el caso de uso administrar cargo.
Ingreso de datos correctos Cargo registrado

en el formulario de registro. correctamente.
Datos del funcionario y

Ingreso de ci correcto en el habilita funciones de
formulario de búsqueda. modificación y
eliminación.

Administrar
Ingreso de ci incorrecto. datos del funcionario no
cargo
existen.

obligatorios.
Ingreso de números donde Mensaje de error tipo de

corresponde letras. dato incorrecto.
153 de 274
3.4. DISEÑO E IMPLEMENTACIÓN DEL SUBSISTEMA DE
CONTROL DE ASISTENCIA, CON EL MÓDULO DE
ASIGNACIÓN DE HORARIOS DE INGRESO Y SALIDAS DEL
PERSONAL INTEGRADO CON EL SUBSISTEMA DE
ADMINISTRACIÓN DE KARDEX.
3.4.1. Análisis.
 El sistema debe permitir realizar el registro de horario de ingreso y salida de

los funcionarios de la institución.
 Debe realizar la búsqueda de las asistencias de los funcionarios
pertenecientes a la institución.
 Compatibilidad
Firefox.
 Disponibilidad
 Extensibilidad
institución.
 Mantenibilidad
154 de 274
 Seguridad
registrado en el sistema, esta facultad de registro de usuarios el único que
puede realizar es el administrador del sistema.
 Usabilidad
ofrece.
Identificación de actores.
Se ha identificado a los siguientes actores: Encargado de RR.HH y Funcionario que

serán representados en el diagrama de caso de uso como se muestra en la siguiente
figura.
Figura 51: Actores del segundo incremento.
uc Actores
Encargado de Funcionario
RR.HH.
Descripción de actores.
Se describe las funciones de los actores a continuación:
Es aquel usuario que puede realizar la administración del horario asignado al
personal contratado como también tiene el privilegio para administrar el
horario de ingreso y salida de los funcionarios.
155 de 274
 Funcionario.
Se encarga de realizar solicitudes de permiso y consulta de reportes sobre su
asistencia.
Figura 52: Casos de uso del sistema del segundo incremento.
156 de 274
Descripción de los casos de uso.
Tabla 21: Documentación del caso de uso administrar asistencia.
CU-6 ADMINISTRAR ASISTENCIA
Precondición Haber registrado datos del funcionario y documentación de kardex.
El encargado y el funcionario pueden ingresar al sistema para poder

acceder a las funcionalidades que otorga de acuerdo al privilegio que
Descripción
tiene, las cuales son: Registrar asistencia, buscar asistencia,
modificar asistencia y eliminar asistencia.
Actor Encargado de RR.HH y Funcionario.
PASO ACCION
El sistema redirecciona a la página de administrar

1 asistencia con las funcionalidades para el usuario que son:
buscar asistencia del personal.
Secuencia normal
El encargado ingresa el número de ci del funcionario para

2
procesar la búsqueda.

3

Post condición
157 de 274
CU-6 ADMINISTRAR ASISTENCIA
PASO ACCION

1

2
Tabla 22: Documentación del caso de uso administrar permisos.
CU-7 ADMINISTRAR PERMISOS
Precondición Haber registrado datos del funcionario y documentación de kardex.

funcionalidades que otorga, las cuales son: Registrar datos del
Descripción
personal, buscar datos del personal, modificar datos del personal y
eliminar datos del personal.
Actor Encargado de RR.HH. y Funcionario.
PASO ACCION

Secuencia normal datos del personal con las funcionalidades de acuerdo al
1
privilegio que son: registrar permisos, buscar permisos,
modificar y eliminar permisos.
158 de 274
CU-7 ADMINISTRAR PERMISOS
El ingresa ingresa el número de ci del funcionario para

2
procesar la búsqueda.

3

Post condición
PASO ACCION

1

2
El registro de datos personales es atribución exclusiva del encargado

Comentarios
de RR.HH.
Diagrama de casos de uso por actor.
Caso de Uso: Administrar asistencia y administrar permisos.
Descripción: Se encarga de la administración de la asistencia de las personas que

trabajan en la institución además es esta persona la que administra el ingreso y
salida de los funcionarios.
159 de 274
En la siguiente figura se detallan las funcionalidades para el segundo incremento
pertenecientes al encargado de recursos humanos, este se encarga de realizar el
control de asistencia y la administración de los permisos los cuales pueden ser
permisos por maternidad, accidente y enfermedad.
Figura 53: Diagrama de casos de uso encargado de RR.HH.
uc Caso de uso por actor
Ingresar al sistema
Modificar asistencia
«extend»
Administrar asistencia Buscar asistencia

«include»
«extend»
Encargado RR.HH.
Eliminar asistencia
Modificar permisos
«extend»
Administrar permisos Buscar permisos

«include»
«extend»
Eliminar permisos
Actor: Funcionario.
Caso de Uso: Administrar asistencia y administrar permisos.
Descripción: Se encarga de realizar búsquedas predefinidas por el sistema, esta

persona es aquella registrar su asistencia y buscar asistencia.
160 de 274
En la siguiente figura se muestra el diagrama de caso de uso por actor para el
funcionario en el que se detallan las funcionalidades para el segundo incremento
pertenecientes al funcionario de la institución, este se encarga de realizar el marcado
de la asistencia y el registro de permisos, los cuales pueden ser permisos por
maternidad, accidente y enfermedad.
Figura 54: Diagrama de caso de uso Funcionario.
uc Caso de uso por actor
Ingresar al sistema
Registrar asistencia
«include»
Administrar asistencia
Funcionario «include»
Buscar asistencia
Registrar permisos
«include»
Administrar permisos
«include»
Buscar permisos
161 de 274
3.4.2. Diseño
Diagrama de Colaboración
Caso de uso: Administrar asistencia.
Figura 55: Diagrama de colaboración administrar asistencia.

sd colaboracion
GESTOR DATOS 1.4: Enviar datos()

PERSONAL
PERSONAL
1.5: Enviar datos de personal() 1.2: Buscar datos()
1: Enviar datos() 1.1: enviar datos para registro() 1.6: Procesar registro()
1.8: asistencia registrada() 1.7: Servicio devuelve valor de registro()
IU ADMINISTRAR IU REGISTRAR
GESTOR REGISTRO REGISTRO
ASISTENCIA ASISTENCIA
1.11: Mensaje de error o datos de asistencia()
1.9: Enviar datos() 1.10: Enviar datos para busqueda()
IU
ASISTENCIA
Caso de uso: Administrar permisos.
Figura 56: Diagrama de colaboración administrar permisos.

sd colaboracion

PERSONAL
PERSONAL
2: Enviar datos() 2.1: Enviar datos para para permisos() 2.6: Procesar permisos()
IU ADMINISTRAR IU REGISTRAR 2.8: Permisos registrado() 2.7: Servicio devuelve valor de registro()
GESTOR PERMISOS PERMISOS
PERMISOS PERMISOS
2.11: Mensaje de error o datos de permisos()
2.9: Enviar datos() 2.10: Enviar datos para busqueda()
IU
PERMISOS

162 de 274
Diagrama de clases
A continuación en la siguiente figura se detalla el diagrama de clases para el

segundo incremento que cuenta con dos nuevas clases que se adicionan al
diagrama anterior y aparecen en un recuadro.
Figura 57: Diagrama de clases del segundo incremento.
163 de 274
Tabla 23: Diccionario de datos de la tabla registro.
REGISTRO
Nombre del
Tipo Descripción
Campo

Idregistro(PK) Int
admite nulos
164 de 274
REGISTRO
Ingresom Time Hora de ingreso en la mañana.
Salidam Time Hora de salida en la mañana.
Ingresot Time Hora de ingreso en la tarde.
Salidat Time Hora de salida en la tarde.
Estado del registro de asistencia que ayuda en el control de la

Estado Varchar2
asistencia diaria.
PERMISOS
Nombre del
Tipo Descripción
Campo

Idpermi(PK) Int
admite nulos
fechainicio Date Fecha de inicio de permiso.
fechafin Date Fecha en que finaliza el permiso.
165 de 274
PERMISOS
Dias Int Días de permisos calculados (Fechainicio - Fechafin).
tipo Varchar2 Tipo de permiso (por lactancia, por accidente por maternidad).
Estado del registro de asistencia que ayuda en el control de la

Estadopermi Varchar2
asistencia diaria.
3.4.3. Pruebas.
En esta fase se realizaron pruebas de funcionalidad por casos de uso, tomando el

caso Encargado de RR.HH. de la aplicación web como tal, de los cuales, se puede
destacar que:

el segundo incremento permite responder al objetivo planteado, el cual, sirve para
realizar el ingreso y salida de los funcionario públicos.
El encargado de RR.HH. se encargará asignar el horario que le corresponde a cada

funcionario de la institución.
Los funcionario pueden registrar su horario de ingreso y salida, así mismo el

encargado de recursos humanos puede administrar esta funcionalidad pudiendo
modificar la asistencia del personal.
166 de 274
A continuación en la siguiente tabla se muestran las pruebas de funcionalidad que se
realizaron en el sistema de control de personal para el caso de uso administrar
asistencia.
Tabla 25: Pruebas para el caso de uso administrar asistencia.
Ingreso de datos correctos en el

Asistencia registrada.
Datos del usuario y habilita

Ingreso de ci correcto en el
funciones de modificación y
formulario de búsqueda.
eliminación.
Ingreso de número de ci no Mensaje de error, el kardex no

existente. existe.
Administrar
asistencia
Mensaje de error los campos
Ingreso de campos vacíos.
Ingreso de números donde Mensaje de error tipo de dato

corresponde letras. incorrecto.
Ingreso de letras donde Mensaje de error tipo de dato

corresponden números. incorrecto.
167 de 274
Tabla 26: Pruebas para el caso de uso administrar permisos.
En la siguiente tabla se detallan las pruebas funcionales realizadas para el caso de

uso administrar permisos.

Permiso registrado.
Datos del usuario y habilita

funciones de modificación y
eliminación.
Ingreso de número de ci no Mensaje de error, el kardex no

existente. existe.
Administrar
permisos


168 de 274
3.5. DESARROLLO DEL SUBSISTEMA DE VACACIONES
INTEGRADO CON EL SUBSISTEMA DE CONTROL DE
ASISTENCIA
3.5.1. Análisis.
 El sistema debe permitir realizar el registro de boletas de vacaciones para

cada funcionario.
 Debe realizar la búsqueda de los de las vacaciones de los funcionarios
 Compatibilidad
Firefox
 Disponibilidad
 Extensibilidad
institución.
 Mantenibilidad
que utiliza el modelo incremental y la Arquitectura Orientada a Servicios
 Seguridad
169 de 274
 Usabilidad
ofrece.

serán representados en el diagrama de caso de uso como se muestra en la figura.
Figura 59: Actores del tercer incremento.
uc actores
Encargado de Funcionario
RR.HH
Es aquel usuario que puede realizar la administración de las vacaciones que
le corresponden a cada funcionario perteneciente a la institución.
 Funcionario.
Es aquel usuario que puede realizar consultas al sistema de control de
personal mediante la introducción de su número de carnet en los campos que
requiere el sistema para procesar la solicitud.
170 de 274
Figura 60: Casos de uso del sistema del tercer incremento.
171 de 274
Tabla 27: Documentación del caso de uso administrar permisos.
CU-8 ADMINISTRAR VACACION

encargado para ser registrado en el subsistema de kardex y además
Precondición
haber creado su cuenta o haber solicitado al administrador una
cuenta.

Actor Encargado y funcionario.
PASO ACCION
Secuencia normal El sistema muestra funcionalidades de acuerdo al

2
privilegio.
El sistema le permite registrar y buscar datos de las

3
vacaciones.

Post condición
172 de 274
CU-8 ADMINISTRAR VACACION
PASO ACCION

1
Excepciones

obligatorios.
Caso de Uso: Administrar vacación.
Descripción: Se encarga de la administración de las vacaciones, de registrar las

boletas de cada funcionario para posteriormente registrar en el control de asistencia.
uc por actor
Ingresar al sistema
Registrar v acacion
Encargado RR.HH. «include»
Administrar v acacion
«include»
Buscar v acacion
173 de 274
Actor: Funcionario.
Caso de Uso: administrar vacación.
Descripción: Se encarga de realizar búsquedas predefinidas por el sistema.
Figura 62: Diagrama casos de uso Funcionario.
uc por actor
Ingresar al sistema
Funcionario
Administrar v acacion
Buscar v acacion
«include»
3.5.2. Diseño
Caso de uso: Administrar vacación.
Figura 63: Diagrama de colaboración administrar vacación.

sd Env iar datos

PERSONAL
PERSONAL
1.5: Enviar datos personal() 1.2: Enviar datos()
1: Enviar datos() 1.1: Enviar datos de boleta() 1.6: Procesar boleta()
1.8: Vacacion registrada() 1.7: Servicio devuelve valor de registro()

IU ADMINISTRAR IU REGISTRAR BOLETA
GESTOR BOLETA
VACACION BOLETA
1.11: Mensaje de error o datos de vacacion()
1.9: Enviar datos()
1.10: Enviar datos de boleta para busqueda()
IU BUSCAR
VACACION
174 de 274
Diagrama de clases
A continuación en la siguiente figura se detalla el diagrama de clases para el tercer

incremento, este diagrama incluye una nueva clase que se adicionó y que se
encuentra remarcada en un recuadro.
Figura 64: Diagrama de clases del tercer incremento.
175 de 274
A continuación en la siguiente figura se muestra el diseño de la base de datos para el

tercer incremento donde se cuenta con una nueva tabla adicionada para realizar el
control de las vacaciones del personal de la institución, la misma que encuentra
remarcada en un recuadro para una fácil identificación, la misma que cuenta con
diferentes atributos como ser un numero de id único, los días de solicitud de
vacación, además esta tabla está relacionada con la tabla donde se almacenan lo
datos del personal.
176 de 274
En la siguiente tabla se detalla el diccionario de datos de la tabla boleta donde se

explican los distintos atributos para un mejor entendimiento y comprensión de la
función que cumple cada uno de ellos.
Tabla 28: Diccionario de datos de la tabla boleta.
BOLETA
Nombre del
Tipo Descripción
Campo

Idboleta(PK) Int
admite nulos
Gestion Int Año actual
Descripcion Varchar2 Descripción del motivo por el cual solicita vacación.
Fechainicio Date Fecha de inicio de la solicitud de vacación
Fechafinal Date Hora de salida en la tarde.
Dias Int Cantidad de días que solicita vacación el funcionario.
Fechasolicitud Date Fecha actual del registro de la boleta.
Cipers (FK) Int Llave foránea que hace referencia a la tabla personal.
Fuente: Elaboración propiaCódigo.
177 de 274
3.5.3. Pruebas.

destacar que:

el tercer incremento permite responder al objetivo planteado, el cual, sirve para
registrar las boletas de vacaciones para cada funcionario.

Caso de uso: Administrar vacaciones.
El encargado puede realizar los registros de las boletas de vacaciones para cada
funcionario cuando estos las necesiten.
Tabla 29: Pruebas para el caso de uso administrar vacaciones.

boleta registrada.
Datos del usuario.
Administrar
vacaciones Ingreso de número de ci no Mensaje de error, el kardex no
existente. existe.

178 de 274


3.6. INTEGRACIÓN DEL SISTEMA BASADO EN ARQUITECTURA

ORIENTADA A SERVICIOS CON DISPOSITIVO DE CONTROL
BIOMÉTRICO.
3.6.1. Selección de dispositivo biométrico.
Tabla 30: Pruebas para el caso de uso administrar vacaciones.
DISPOSITIVO CARACTERÍSTICAS
Distintos modos de operación: Sólo tarjetas, Código + Tarjeta y

Código + Password,
cambio de hora automático verano-invierno, incorpora puerto

USB para la descarga de fichajes a una unidad portátil (Pendrive
TR-ICLOCK 260
o Flash Disk),
cambio de hora automático verano-invierno, permite la respuesta

del terminal al fichar a través de voz., admite la introducción de
ilimitadas incidencias (Fumar, Comida, Asuntos, Médico, etc)
Métodos de identificación incluyen la cara, Fingerprint / RFID y /

iFace402 o contraseña, diseño ergonómico elegante pantalla táctil de 4.3''
TFT es muy intuitivo fácil de usar.
179 de 274
DISPOSITIVO CARACTERÍSTICAS
Lee las huellas digitales más difíciles, está pensado para el

desarrollo de sistemas, su costo es económico y en los últimos
DigitalPersona
tiempos ha tenido mucha aceptación por los desarrolladores de
software.
Para realizar el presente proyecto se consideraron los tipos de dispositivos que se

muestran en la tabla anterior, a partir de esto se llegó a seleccionar el Digital
Persona, que es un dispositivo adecuado para el desarrollo y pruebas de sistemas
que requieren el manejo de la identificación biométrica.
3.6.2. Análisis.
 El sistema debe permitir realizar el registro de las huellas de los funcionarios

de la institución.
 Disponibilidad
 Extensibilidad
institución.
 Mantenibilidad
que utiliza el modelo incremental y la Arquitectura Orientada a Servicios
180 de 274
 Seguridad

serán representados en el diagrama de caso de uso como se muestra en la figura.
Figura 66: Actores del cuarto incremento.
uc actores
Encargado de
RR.HH.
Es aquel usuario que puede realizar el registro de las huellas del funcionario
público.
A continuación en la siguiente figura se muestra el diagrama de casos de uso del

sistema para el cuarto incremento donde se adicionan un nuevo caso de uso,
administrar huellas, además se modifican dos casos de uso para permitir leer las
huellas dactilares.
181 de 274
Figura 67: Casos de uso del sistema del cuarto incremento.
182 de 274
Tabla 31: Documentación del caso de uso administrar huellas.
CU-9 ADMINISTRAR HUELLAS

Precondición encargado para ser registrado en el subsistema de kardex y además
haber sido registrado en el subsistema de asistencia.

Actor Encargado.
PASO ACCION
Secuencia normal El sistema muestra funcionalidades de acuerdo al

2
privilegio.
El sistema le permite registrar, buscar, modificar y eliminar

3
las huellas de los funcionarios.

Post condición
183 de 274
CU-9 ADMINISTRAR HUELLAS
PASO ACCION

1

obligatorios.
Excepciones
Para registrar la huella de un nuevo funcionario debe tener

3 registrado sus datos personales en el subsistema de
kardex.
Si se genera una excepción el sistema no se cuelga sino

4 que muestra un mensaje en el cual dice: “Se ha producido
una excepción al ejecutar el proceso.”
Caso de Uso: Administrar vacación.
Descripción: Se encarga de la administración de las vacaciones, para registrar una

vacación los datos del funcionario deben estar registrados en el subsistema de
kardex, caso contrario no se podrá procesar los datos, este usuario se encarga de
registrar las boletas de cada funcionario para posteriormente registrar en el control
de asistencia.
184 de 274
uc caso por actor
Ingresar al sistema
Administrar datos del Registrar datos del

personal «include» personal
Encargado RR.HH. Modificar asistencia
«extend»
Administrar asistencia Buscar asistencia
«include»
«extend»
Eliminar asistencia
Registrar huella
«include»
Administrar huellas
Modificar huella
«include»
«extend»
Buscar huella
«extend»
Eliminar huella
Actor: Funcionario.
Caso de Uso: administrar asistencia.
Descripción: Este usuario se encarga de registrar su asistencia en el sistema, para

lo cual sus huellas deben estar registradas en el subsistema de asistencia, si la
persona no se encuentra registrada no podrá marcar su horario de ingreso o de
salida.
185 de 274
Figura 69: Diagrama casos de uso Funcionario.
uc caso por actor
Ingresar al sistema
Administrar asistencia Registrar asistencia

«include»
Funcionario
Administrar huellas Buscar huella

«include»
3.6.3. Diseño
A continuación se muestran los diagramas de colaboración para cada caso de uso.
Figura 70: Diagrama de colaboración administrar datos del personal.

3: Enviar datos() 3.1: Enviar datos personal() 3.2: Procesar datos personal()
3.4: Datos registrados() 3.3: Servicio devuelve valor de registro()

PERSONAL
IU ADMINISTRAR IU REGISTRAR GESTOR PERSONAL
DATOS DEL NUEVOS DATOS
PERSONAL
186 de 274
Figura 71: Diagrama de colaboración administrar asistencia .
sd colaboracion

PERSONAL
PERSONAL
1: Enviar datos() 1.1: enviar datos para registro() 1.6: Procesar registro()
1.8: asistencia registrada() 1.7: Servicio devuelve valor de registro()
IU ADMINISTRAR IU REGISTRAR
GESTOR REGISTRO REGISTRO
ASISTENCIA ASISTENCIA
Caso de uso: Administrar huellas.
Figura 72: Diagrama de colaboración administrar huellas.

sd colaboracino
1.4: Enviar datos()

GESTOR PERSONAL PERSONAL
1: Enviar datos() 1.1: Enviar datos para registro() 1.6: Procesar registro()
1.8: Permiso registrado() 1.7: Servicio devuelve valor de registro()
IU ADMINISTRAR IU REGISTRAR GESTOR BIOMETRICO
HUELLA HUELLA BIOMETRICO
1.11: Mensaje de error o datos de permisos()
1.9: Enviar datos() 1.10: Enviar datos de permisos para busqueda()
IU BUSCAR HUELLA
187 de 274
Diagrama de clases
En la siguiente figura se muestra el diagrama de colaboración para este incremento.
Figura 73: Diagrama de clases del cuarto incremento.
188 de 274

cuarto incremento donde se realizará la integración del sistema de control de
personal con sus diferentes subsistemas (Kardex, Asistencia, Vacaciones), con el
dispositivo de control biométrico mediante la creación de un nuevo servicio web que
interactuará con la tabla biométrico que se encuentra remarcada para su mejor
comprensión.
189 de 274
Tabla 32: Diccionario de datos de la tabla biométrico.
BIOMETRICO
Nombre del
Tipo Descripción
Campo

IDBIO(PK) Int
admite nulos
Huella perteneciente a uno de los dedos del funcionario de la

huella Varchar2
institución.
dedo Int Numero de dedo al que pertenece el campo huella.
CIPERS(FK) Int Llave foránea que hace referencia a la tabla personal..
3.6.4. Código.
Según las herramientas y lenguaje de programación seleccionados para la

implementación del presente proyecto (MS Visual Studio 2010 y C#.NET) en base a
SOA, se utilizará los servicios web de asp.net.
Los servicios web de asp.net. Están disponibles en la versión 3.5 del framework de
.NET.
Para realizar la integración entre el dispositivo biométrico digital persona y el sistema

de control de personal se hizo uso de un servicio web.
190 de 274
Figura 75: Creación de un servicio web.
Servicio web ASP.NET del dispositivo biométrico.
Se creó el servicio web que permite la integración como se muestra en la siguiente

figura.
Figura 76: Configuraciones y Web Method.
191 de 274
De esta manera se logra la integración del sistema de control de personal con el
dispositivo biométrico.
3.6.5. Pruebas.

destacar que:

el cuarto incremento permite responder al objetivo planteado, el cual, sirve para
registrar las boletas de vacaciones para cada funcionario.
El encargado de RR.HH. se encargará registrar las huellas que le corresponden a

cada funcionario.
El encargado puede realizar los registros de huella dactilares de los funcionarios.
Tabla 33: Pruebas para el caso de uso administrar huellas.
Ingreso de datos correctos en el Huella registrada.

Ingreso de campos vacíos. Mensaje de error los campos

Administrar en * son obligatorios.
huellas

192 de 274

3.7. IMPLEMENTACIÓN DE MECANISMOS PARA LA GENERACIÓN

Y EXPORTACIÓN DE REPORTES DE VERIFICACIÓN DE
CONTROL DE KARDEX, ASISTENCIA Y VACACIONES.
3.7.1. Análisis.
 El sistema debe permitir realizar generación de reportes.
 Disponibilidad
 Extensibilidad
institución.
 Mantenibilidad
193 de 274
 Seguridad
Se ha identificado a los siguientes actores: Encargado de RR.HH que serán

representados en el diagrama de caso de uso como se muestra en la figura.
Figura 77: Actores del quinto incremento.
uc actores
Administrador de
Sistemas
 Administrador de sistemas.
Es aquel usuario que puede generar y exportar a los diferentes formatos los
diferentes tipos de reportes que generan el sistema de control de personal con
sus diferentes subsistemas (Subsistema de kardex, subsistema de asistencia,
subsistema de vacaciones), los formatos a los cuales puede exportar los
distintos reportes son Word, PDF y Word (los formatos de exportación fueron
elegidos de acuerdo a los requerimientos de la institución).
194 de 274
Figura 78: Casos de uso del sistema del quinto incremento.
195 de 274
Tipos de generación y exportación de reportes.
Tipos de generación de reportes.
Tabla 34: Características de los reporteadores.
TIPO CARACTERISTICAS
Es un generador de reportes multi-plataforma, una

herramienta de consulta y generación de gráficos como el
Crystal Reports que se conecta a várias Bases de Datos,
Agata como PostgreSQL, MySQL, Oracle, DB2, MS-SQL,
Informix, InterBase, Sybase, o Frontbase y permite
exportar los reportes en formatos como PostScript, plain
text, HTML, XML, PDF o CSV (StarCalc, Excel).
Crystal Reports para Visual Studio proporciona una forma

muy productiva de crear e integrar informes interactivos
Crystal Reports
con calidad de presentación en las aplicaciones para
Windows, Web o servicios Web XML.
Es una herramienta para generar y compartir consultas y

Codisa Query Builder reportes a partir de las diferentes fuentes de datos con las
que cuente su organización.
Del listado mencionado en la tabla anterior se seleccionó Crystal Reports porque

proporciona una forma muy productiva de crear e integrar informes interactivos con la
plataforma .NET.
196 de 274
Tipos de exportación de archivos
Tabla 35: Ventajas y desventajas de los tipos de exportación.
TIPO VENTAJAS DESVENTAJAS
Requiere de la ejecución de un “plug-

Posibilidad de compartir in”
documentos con cualquier Requiere contar con las últimas ver-
persona. siones del lector (5 o superior)
El estado de la accesibilidad de he-
Facilidad de uso.
rramientas no esta tan avanzado co-
PDF mo su equivalente para HTML (p. ej.
Intercambio de documen-
Hay problemas con tablas que
tos más seguro. Más livia-
197álcu ya usables en HTML)
nos.
Es más sencillo crear un documento
Varios formatos en un HTML plenamente accesible que un
único documento. PDF con sus limitadas opciones de
accesibilidad
Operaciones aritméticas
con fórmulas...
Tablas dinámicas.
Hay que comprarlo, y no es tan
Ordenar datos fácilmente.
barato. Solo es compatible con 197
Cálculos y con mac.
Separar tablas de texto en
Excel
columnas.
Muy ineficiente, los archivos ocupan
mucho espacio, aunque hagas
Filtrar datos.
cálculos sencillos.
Creación de listas.
Elaboración de gráficos de
manera rápida y sencilla.
197 de 274
3.7.2. Diseño
Figura 79: Diagrama de clases del quinto incremento.
El diagrama de clases para el quinto incremento no cambia, porque para este avance
solo se realiza la generación y exportación de los reportes, que se obtiene de las
clases del diagrama.
198 de 274

quinto incremento, lo que permitirá obtener el reporte mediante el encargado de
recursos humanos para todos los requerimientos de la institución.
199 de 274
El diagrama de base de datos no sufre ningún cambio en este incremento, porque los
datos que se utilizan para los reportes, se obtienen de las tablas que se muestran en
el diagrama.
A continuación en las siguientes tablas se muestran los diferentes atributos que se

añadieron a la base de datos para obtener de manera sencilla, rápida e íntegra los
distintos reportes e informes que se pueden ser generados con el sistema de control
de personal.
Las tablas afectadas en la base de datos son las siguientes:
 PERSONAL: Contiene los datos del personal de la institución que forman

parte del subsistema de kardex.
 REGISTRO: Se encarga de guardar los datos de la asistencia de los
funcionarios públicos.
 PERMISOS: Almacena los datos de los permisos de los funcionarios públicos
de acuerdo a la fecha de solicitud del permiso.
 BOLETA: Esta tabla contiene los registros de vacación de los funcionarios
Tabla 36: Diccionario de datos de la tabla personal.
PERSONAL
Nombre del
Tipo Descripción
Campo
fechamodif Date Fecha de modificación o actualización de la documentación.
200 de 274
REGISTRO
Nombre del
Tipo Descripción
Campo
Fecha Date Fecha donde el funcionario marca el ingreso y salida.
Fecha que facilita al sistema la obtención de los reportes de la

Fechas Varchar2
tabla registro.
Tipo de asistencia: maternidad (7 horas) o asistencia normal

Especial Varchar2
(8horas).
Numsem Int Numero de semana de acuerdo al año numeradas del 1 al 52.
Ano Int Año actual obtenido de la hora del sistema.
Tabla 38: Diccionario de datos de la tabla permisos.
PERMISOS
Nombre del
Tipo Descripción
Campo
Descripcion Varchar2 Descripción del permiso que se solicita.
fechapermi Date Fecha de solicitud del permiso.
201 de 274
PERMISOS
Estado del permiso: pendiente (No ha sido aceptado ni

Estadopermi Date
rechazado), aceptado y rechazado.

Fechapermis Int
tabla permisos.
numsem Int Numero de semana de acuerdo al año numeradas del 1 al 52.
ano Varchar2 Año actual obtenido de la hora del sistema.
Tabla 39: Diccionario de datos de la tabla boleta.
BOLETA
Nombre del
Tipo Descripción
Campo
años Int Años de antigüedad del funcionario público.
diasvacacion Int Días de vacación restantes para el funcionario.

Fechasolicituds Varchar2
tabla boleta.
numsem Int Numero de semana de acuerdo al año numeradas del 1 al 52.
202 de 274
3.7.3. Arquitectura del sistema completo.
En base a la estructura de la Arquitectura Orientada a Servicios y el desarrollo de los

módulos completos se tiene:
 Subsistema de kardex.
 Subsistema de asistencia.
 Subsistema de vacaciones.
 Dispositivo biométrico.
Figura 81: Arquitectura del sistema completo.
LOG DE
USUARIOS
SHA-512
SERVIDOR DE PUBLICACION
Administrador
BASE DE DATOS DE SERVICIOS
CONTROL
POR IP App Subsistema
SOAP de Kardex
web
XML App
Subsistema de
escritorio
Vacaciones
SHA-512
SERVICIOS
WEB Subsistema de
WSDL Asistencia
Encargado
SHA-512
Dispositivo
biométrico
Funcionario
HTTP SEGURIDAD
203 de 274
3.7.4. Código.
Crear reporte.
Para crear un reporte en cristal reports se debe tener un dataset con una tabla con
los datos que queremos imprimir.
Por otro lado, se debe crear un formulario y colocarle un control CrystalReportViewer.
En dicho formulario se crea una sobrecarga sobre el constructor para pasarle el

reporte como parámetro:
public FrmReportes(CrystalDecisions.CrystalReports.Engine.ReportDocument
Reporte)
InitializeComponent();
this.CrvReportes.ReportSource = Reporte;
this.CrvReportes.Show();
this.ShowDialog();
Solo nos queda pendiente llamar al formulario contenedor del reporte pasandole
como parametro el reporte:
CrystalDecisions.CrystalReports.Engine.ReportDocument mirepo;
mirepo = new RptReporte();
//asignamos el dataset para que actualice los datos:
mirepo.Database.Tables["Table1"].SetDataSource(ds);
204 de 274
//llamamos al contenedor
FrmReportes FrmRepor = new FrmReportes(mirepo);
Exportación de los reportes.
Una de las facilidades de crystal reports es que permite la exportación automática de

los reportes a archivos pdf y Excel además de otras extensiones.
Figura 82: Exportación de reportes en CrystalReports.
Así de esta manera cristal reports facilita el desarrollo de código para la exportación
de los reportes a las diferentes extensiones, ayudando al desarrollador a reducir
líneas de código.
3.7.5. Pruebas.
En esta fase se realizaron pruebas de generación de reportes, para verificar si el

incremento cumple con el objetivo.

el quinto incremento permite responder al objetivo planteado, el cual, sirve para
generar y exportar reportes del sistema.
205 de 274
Caso de uso: Generar y exportar reportes.
El encargado puede realizar los reportes necesarios para las tablas de la base de
datos cuando estos se necesiten.
Tabla 40: Pruebas para el caso de uso generar y exportar reportes.
Ingreso de datos para la

Datos de reportes.
generación de reportes.

Generar y
exportar reportes.

3.8. PRUEBAS DE VERIFICACION DE FUNCIONAMIENTO DEL

SISTEMA.
3.8.1. Pruebas Unitarias.
Una prueba unitaria es buena cuando:
 Es automatizable: donde no se requiere una intervención manual.
 Cubren la mayor cantidad de código.
206 de 274
 Repetibles o reutilizables: pruebas que se utilizan más de una vez.
 Independientes: la ejecución de una prueba no afecta la ejecución de otra.
 Profesionales: las pruebas deben ser consideradas igual que el código, con la
misma profesionalidad, documentación, etc.
Algunas ventajas de utilizar pruebas unitarias son:
 Fomentan el cambio: facilitan el cambio de código para mejorarlo asegurando

que los cambios no introduzcan errores.
 Sirven como documentación.
 Los errores están más acotados y son más fáciles de localizar: dado que
tenemos pruebas unitarias que pueden desenmascararlos.
Para este proyecto se desarrollaron pruebas unitarias para los servicios web que
pertenecen a cada subsistema.
Subsistema de Kardex.
Figura 83: Verificación de las pruebas unitarias para el subistema de kardex.
207 de 274
Subsistema de Asistencia.
Figura 84: Verificación de las pruebas unitarias para el subsistema de asistencia.
Subsistema de Vacaciones.
Figura 85: Verificación de las pruebas unitarias para el subsistema de vacaciones.
Tras realizar estas pruebas sobre los elementos unitarios del programa se logró
eliminar gran parte de los errores de los que podría adolecer. Como se sabe
cualquier prueba demuestra no la ausencia de errores sino que revela la presencia
de ellos. Las pruebas unitarias no revelan errores en la integración de las partes
208 de 274
unitarias, ni tampoco otros problemas como el bajo rendimiento de las aplicaciones o
problemas derivados del sistema sobre el que está ejecutándose el programa.
El objetivo de las pruebas unitarias es el aislamiento de partes del código y la

demostración de que estas partes no contienen errores.
3.8.2. Pruebas de Integración.
En base a las pruebas unitarias realizadas para los servicios del sistema de control
de personal, viendo que el resultado de las pruebas es satisfactorio, de manera
implícita se demuestran las pruebas de integración ya que los servicios siguen una
cadena de comunicación que los interconecta entre sí.
Servicios del SISKAV:
 Servicio de Kardex, Servicio de Asistencia, Servicio de Vacaciones,

 Servicio de dispositivo.
En el primer servicio se tiene el subsistema de kardex, en el segundo servicio se

tiene asistencia, al emplearse el registro de asistencia se solicita datos a kardex, la
prueba de unidad garantizó que los dos subsistemas (kardex y asistencia) están
funcionando correctamente, por tanto al realizar esta solicitud se realiza la
integración de ambos servicios y se puede evidenciar las fallas en el caso de no
existir recuperación de datos o el buen funcionamiento si aparece la información
necesaria.
En el subsistema de vacaciones se realiza el registro de una nueva solicitud de

vacación, para lo cual este servicio se interconecta con el servicio de kardex para
obtener la información necesaria.
Al realizar el registro y verificación de asistencia el servicio biométrico se interconecta

con el servicio de kardex para obtener la información de los funcionarios, como los
resultados de las pruebas unitarias fueron correctas, se logra la integración de
ambos servicios con lo cual se obtiene la información requerida.
209 de 274
Otra prueba de integración que se realizo fue entre el servicio de asistencia, con el
servicio de vacaciones y kardex, donde a partir de la solicitud de un permiso, se
interconectan los diferentes servicios web para obtener la información necesaria
respecto a los días de vacación solicitados y usados, de la misma manera se
interconecta con el servicio de kardex para obtener los datos del funcionario.
Figura 86: Integración de servicios web para la obtención de reportes.
Interfaz de
P.U. del
obtención de Servicio
servicio de
kardex
reportes kardex
Reporte de SERVICIOS
Asistencia DE UDDI
Servicio P.U. del

servicio de
asistencia asistencia
BD
CONTROL
Interfaz de
P.U. del
obtención de Servicio
servicio de
kardex
reportes kardex
Base de datos
Reporte de SERVICIOS del sistema de
Vacaciones DE UDDI control
Servicio P.U. del

servicio de
vacaciones vacaciones
210 de 274
En la figura 86 se muestra en una gráfica la integración de los diferentes servicios del
sistema donde se muestra en la primera columna las diferentes interfaces donde se
generarán los reportes, en la segunda columna los servicios que anteriormente
fueron sometidos a las pruebas de unidad y la conexión con el servidor de uddi,
finalmente en la tercera columna se refleja la base de datos del sistema de control de
personal.
3.9. DEMOSTRACIÓN DE LA HIPÓTESIS.
La hipótesis planteada en el proyecto actual cita: “Un Sistema de Control de Personal

aplicando la Arquitectura Orientada a Servicios e integrado al dispositivo biométrico
permitirá reducir el tiempo invertido en el proceso de control de asistencia e
identificación de los funcionarios públicos, disminuir los errores en la elaboración de
los reportes respectivos y obtener reportes clasificados para información de
vacaciones”.
Para demostrar la hipótesis es necesario analizar las variables dependientes de la

hipótesis las cuales son:
 Tiempo invertido en el proceso de control de asistencia e identificación de los

funcionarios públicos, que se ve reflejado en la cantidad de tiempo para dar
cumplimiento al proceso de control de personal.
 Errores en la elaboración de los reportes respectivos: donde se considera la
reducción de errores en la emisión de reportes del sistema para control de
personal, con información de mayor consistencia, que la utilizada actualmente.
 Reportes clasificados para información de vacaciones, en esta variable
dependiente se toma en cuenta los diferentes reportes generados por el
sistema de acuerdo a los requerimientos de la institución.
Además es necesario realizar la demostración de hipótesis para la variable

independiente: Sistema de Control de Personal aplicando la Arquitectura Orientada a
211 de 274
3.9.1. Demostración de la primera variable dependiente.
Para la demostración de la primera variable: “tiempo invertido en el proceso de

control de asistencia e identificación de los funcionarios públicos.”, se realiza un
análisis del proceso actual que se sigue dentro de la institución para el control de
asistencia de una sola persona, para lo cual se realizó el cálculo de los tiempos
respectivos para cada proceso ,posteriormente se realiza una tabla comparativa para
poder identificar la cantidad de tiempo invertido en el proceso del control del
personal.
Tabla 41: Comparación de tiempos en los procesos.
CON SISTEMA SIN SISTEMA
Pasos a seguir Tiempo Pasos a seguir Tiempo
Verificar documentación:
Verificar documentación:
 .Verifica
 Se accede al sistema de documentación de
2 min. 20 min.
acuerdo al privilegio. cada funcionario.
 Se accede a los reportes  Registra en la
y se presiona el botón. planilla Excel uno a
uno.
Registro biométrico:
Registro biométrico:
 El encargado
 El encargado ingresa al
accede al software y
sistema. 5 min. 15 min.
solicita los datos del
 Solicita el número de ci al
funcionario.
funcionario y registra las
 Registra los datos
huellas.
del funcionario.
212 de 274
Información de asistencia:
Información de asistencia.
 Dirigirse a las
 El encargado accede al
oficinas de recursos.
sistema de acuerdo al 3 min. 30 min.
 Apersonarse con el
privilegio.
encargado.
 Accede a los reportes y
 Solicitar información
se presiona el botón.
de asistencia.
Consultar información de
Consultar información de faltas: faltas:
 El encargado accede al  Dirigirse a las

sistema de acuerdo al 2 min. oficinas de recursos. 30 min.
privilegio.  Apersonarse con el
 Accede a los reportes y encargado.
se presiona el botón.  Solicitar información
referente a faltas.
permisos:
permisos:
 Dirigirse a las
 El encargado accede al
2 min. oficinas de recursos. 30 min.
sistema de acuerdo al
 Apersonarse con el
privilegio.
encargado.
 Accede a los reportes y
 Solicitar información
se presiona el botón.
de permisos.
213 de 274
Solicitud de permiso para una Solicitud de permiso para

fecha determinada. una fecha determinada.
 El funcionario accede al  Dirigirse a las
sistema. 2 min. oficinas de recursos. 1 h.
 Ingresa a la ventana de  Apersonarse con el
permisos y registra su encargado.
permiso.  Solicitar permiso.
Total 16 min. Total 185 min.
En la tabla superior se muestra la tabla comparativa del proceso actual

implementado en la institución para el proceso de control de asistencia, en el cual se
obtuvo que con el proceso actual se invierte 185 min. y que con el sistema de control
de personal aplicando la arquitectura orientada a servicios integrado con dispositivo
biométrico se obtiene en el mismo proceso 16 min.
A continuación se aplicaran fórmulas a los datos obtenidos para poder llegar a una
conclusión.
Del cálculo de las ecuaciones anteriores se deduce que con el uso del sistema de
control de personal aplicando la arquitectura orientada a servicios e integrado con
dispositivo biométrico se obtiene un tiempo de 16 min lo cual implica una reducción
del 91,35% en el proceso de control de control de asistencia e identificación de los
funcionarios de la institución.
214 de 274
3.9.2. Demostración de la segunda variable dependiente.
En la demostración de la segunda variable dependiente: “errores en la elaboración

de los reportes respectivos”, se hará uso de una tabla comparativa de los reportes
que generan los sistemas actuales de la institución, como ser: el sistema de
asistencia, control de kardex y el sistema de vacaciones, con los reportes que se
pueden obtener con el sistema de control de personal aplicando la arquitectura
orientada a servicios e integrado con dispositivo biométrico (Sistema propuesto).
Entre los principales tipos de errores detectados están: error de transcripción al

momento de introducir datos a hoja Excel en base a una verificación visual de la
documentación de kardex, error de transcripción al realizar la planilla de asistencia
mensual debido a que se comparan las diferentes planillas de cada unidad, demora
en la entrega de planillas de asistencia para el sistema de sueldos y salarios, etc .
En la siguiente tabla se muestran los reportes generados por ambos sistemas:
Tabla 42: Comparación de cantidad de errores.
OBTENCION DE
# DE ERRORES
TIPOS DE
# DE ERRORES (Sistema
REPORTES DEL
(Sistema actual)
ERRORES
propuesto)
SISTEMA
Error de transcripción al Se obtiene información de

momento de introducir kardex de manera
datos a hoja Excel en automática debido a la
base a una verificación 3 integración de los 0
visual de la sistemas que da facilidad
documentación de de procesamiento de la
kardex. información.
215 de 274
OBTENCION DE
# DE ERRORES
TIPOS DE
REPORTES DEL
(Sistema actual)
ERRORES
propuesto)
SISTEMA
Error de transcripción al
El sistema genera
realizar la planilla de
información automática
asistencia mensual
4 debido a la integración del 0
debido a que se
sistema con el dispositivo
comparan las diferentes
biométrico.
planillas de cada unidad.
Error de transcripción al El sistema realiza la

realizar la planilla de generación de y el envío
asistencia para el de los datos de asistencia
sistema de sueldos y y permisos de forma
salarios al momento de 3 automática para el SGSS 1
comparar la planilla de (Sistema de gestión de
asistencia en excel con sueldos y salarios),
las planillas de permisos haciendo uso de la
en excel. arquitectura SOA.
Demora en la entrega de Con el SISKAV no existe

planillas de asistencia demora en la entrega de
para el sistema de los datos debido a que las
sueldos y salarios antes funcionalidades están
del 23 de cada mes 2 reflejadas como servicios 0
genera molestias por por tanto el SGSS puede
parte del personal o que recopilar la información en
no se cancele el sueldo cualquier momento para
en fecha establecida. poder realizar la planilla.
216 de 274
OBTENCION DE
# DE ERRORES
TIPOS DE
REPORTES DEL
(Sistema actual)
ERRORES
propuesto)
SISTEMA
Duplicación de datos por

parte de los encargados
de elaborar las planillas
Entrega de reportes
mensuales debido a que
mensuales sin duplicación
cada planilla tiene los
de datos debido a la
mismos datos
integración de los
cambiando solamente el 2 0
sistemas de kardex,
campo permiso por
asistencia y vacaciones
asistencia o falta , lo
utilizando la arquitectura
cual genera demora y
orientada a servicios.
posibles errores al
comparar las diferentes
planillas.
Total sistema actual. 14 Total sistema propuesto. 1
En la actualidad el personal se encuentra insatisfecho debido a que la elaboración de

planilla de sueldos demora más del tiempo establecido, ya que la forma de
confección de dichos reportes pasa por muchas fases y utiliza información
incompleta que debe ser verificada, estas deficiencias son cubiertas por el sistema
desarrollado en este proyecto, ya que integra los procesos manuales de la gestión de
kardex realizados actualmente, con el sistema de asistencia y vacaciones, lo que le
permite generar las diferentes planillas de manera rápida y sencilla, ofreciéndole a
los usuario la posibilidad de exportación a distintos formatos de archivos requeridos
por la institución.
217 de 274
3.9.3. Demostración de la tercera variable dependiente.
En la demostración de la tercera variable dependiente se realizará una tabla

comparativa de acuerdo al rol de usuario en el sistema y al proceso actual, para ello
se identificarán los diferentes tipos de reportes que se obtienen.
Tabla 43: Comparación de tipos de reportes.
TIPOS DE
USUARIO CON SISTEMA SIN SISTEMA
REPORTES
No se genera
El sistema genera este actualmente ya que el
tipo de reporte mostrando sistema solo cuenta con
Reporte de
por pantalla una lista de un usuario y no se vio la
Administrador usuarios del
todos los funcionarios con necesidad de contar con
sistema.
sus cuentas que tienen en este reporte debido a que
el sistema. solo existe un usuario en
cada sistema.
No existe este tipo de

Se genera de manera reporte debido a que
Reporte de
automática obteniendo la actualmente se realiza el
datos del
Encargado lista de todos los procesamiento de esta
personal de la
funcionarios con sus datos información de forma
institución.
personales. manual llenando una hoja
Excel.
218 de 274
TIPOS DE
USUARIO CON SISTEMA SIN SISTEMA
REPORTES
Genera este tipo de Actualmente este reporte

reporte mostrando una no existe debido a que los
Reportes de
lista de los datos de los sistemas de asistencia y
acceso al
usuarios, la fecha de vacaciones actuales
Administrador sistema por
acceso y la hora para que fueron desarrollados para
parte de los
la institución pueda crear escritorio y cuentan con
usuarios.
estadísticas a partir de un solo usuario que tiene
estas. todos los privilegios.
Actualmente este tipo de

reporte no existe ya que
El siskav genera de forma
el proceso se lo realiza de
automática este tipo de
forma manual realizando
Reportes de reporte mostrando una
el llenado de las listas en
Encargado documentación lista de la documentación
hojas de Excel
del personal. de cada funcionario de la
comparando las
institución con sus datos
diferentes hojas de
personales.
control de cada archivo
personal.
El funcionario de la
institución interactúa con
No existe debido a que no
el sistema pudiendo ver
existe participación de los
Consulta al diferentes tipos de reporte,
Funcionario funcionarios en los
sistema. lo cual le facilita la
sistemas actuales de la
obtención de información
institución.
sin tener que trasladarse
de un lugar a otro.
219 de 274
Algunos de los reportes que se pueden obtener con el sistema son los siguientes:
Figura 87: Reporte en gridview.
Figura 88: Reporte en Reportviewer.
220 de 274
Figura 89: Reporte en CrystalReports.
En la actualidad la institución sufre de la carencia de reportes integrales que le

brinden información que considere las áreas de vacaciones, asistencia y los datos
personales de los funcionarios, lo cual se cubre con el uso del sistema desarrollado
ya que este cuenta con toda la información de las áreas mencionadas anteriormente
lo que le permite generar diferentes tipos de reportes de una manera rápida y
sencilla, ofreciéndole a los distintos usuarios la posibilidad de exportación a distintos
formatos de archivos requeridos por la institución.
3.9.4. Demostración de la variable independiente.
En la demostración de la variable independiente, se realiza el análisis a través de

una muestra de todos los beneficios que se obtienen del sistema propuesto, y los
procedimientos manuales empleados sin el uso del sistema, para el proceso de
control de personal. Los beneficios de esta tabla se las ha obtenido del modelado de
221 de 274
negocio actual y alternativo reflejado en el marco práctico en el punto 3.1. y 3.2.
Calificando como un beneficio con la palabra “Sí”, y rechazando el beneficio con la
palabra “No” en la siguiente tabla:
Tabla 44: Tabla comparativa de beneficios del sistema propuesto.
Proceso
Proceso
Nro. Factores Tomados en Cuenta Como con el
Manual
Factor Beneficio sistema
(Antes)
(Actual)
Permite registrar datos del personal de la

1 Si Si
institución.
Permite obtener datos de los funcionarios de

2 forma rápida. Si No
Permite obtener información oportuna de la

3 Si No
documentación de un funcionario.
Permite registrar las 10 huellas dactilares de un

4 Si No
funcionario.
Permite obtener reportes de asistencia vinculados

5 Si No
con los datos de kardex de manera flexible.
Permite marcar ingresos y salidas por medio de

6 un dispositivo biométrico de acuerdo al horario Si Si
establecido por la institución.
Permite realizar la gestión de permisos de

7 Si No
manera rápida y oportuna para cada funcionario.
Permite registrar días de vacaciones para cada

8 Si Si
222 de 274
Proceso
Proceso
Nro. Factores Tomados en Cuenta Como con el
Manual
Factor Beneficio sistema
(Antes)
(Actual)
Permite obtener reportes relacionados con los

9 días de vacación considerando las faltas y Si No
permisos de los funcionarios.
Permite la generación de informes en distintos

formatos relacionando la información existente de
10 Si No
los subsistemas de asistencia, kardex y
vacaciones.
Total beneficios 10(si) 3 (si)
Teniendo en cuenta los resultados obtenidos del análisis de las muestras de la tabla
anterior, se concluye que el total de beneficios por el proceso manual tiene la
cantidad de 3, y con el proceso del sistema es de 10. Estos resultados se tomarán
en cuenta en el cálculo de estadístico T para realizar la aceptación o rechazo de la
hipótesis que se detalla a continuación.
3.9.4.1. Definición de la hipótesis.
Para definir la hipótesis se considera el análisis de aceptación o rechazo de la

misma, haciendo referencia a un que representa una probabilidad, en este caso se
tiene que:
 = Los procedimientos manuales y los sistemas utilizados en la actualidad

para el control de kardex, asistencia y vacaciones.
 = El sistema de control de personal aplicando la Arquitectura Orientada a

Servicios integrado con dispositivo biométrico.
223 de 274
Para realizar la demostración en la comparación de beneficios se plantean las
siguientes hipótesis:
 Hipótesis nula: Los factores de éxito de antes son iguales a los factores de
éxito posteriores :
 Hipótesis alternativa: Los factores de éxito de antes son distintos a los

factores de éxito posteriores :
Dentro de la hipótesis alternativa se presentan dos casos, los cuales son:
o Los factores de éxito anteriores son mayores a los posteriores:
o Los factores de éxito anteriores son menores a los posteriores:
Y en el proyecto se tiene que:
 : (Los procedimientos manuales y los sistemas utilizados en la

actualidad para el control de kardex, asistencia y vacaciones es igual al sistema
de control de personal aplicando la Arquitectura Orientada a Servicios integrado
con dispositivo biométrico).

actualidad para el control de kardex, asistencia y vacaciones es diferente del
sistema de control de personal aplicando la Arquitectura Orientada a Servicios
integrado con dispositivo biométrico).

actualidad para el control de kardex, asistencia y vacaciones tiene mayores
beneficios que el sistema de control de personal aplicando la Arquitectura
Orientada a Servicios integrado con dispositivo biométrico).
224 de 274
actualidad para el control de kardex, asistencia y vacaciones tiene menores
beneficios que el sistema de control de personal aplicando la Arquitectura
Orientada a Servicios integrado con dispositivo biométrico).
3.9.4.2. Cálculo del estadístico T.
Este cálculo permite conocer la aceptación de la hipótesis, teniendo en cuenta que

existe un rango de aceptación. Luego con el dato encontrado con las probabilidades
se ubica si está dentro del rango de aceptación o rechazo. Para ello se realiza los
cálculos con las siguientes fórmulas:

√
Dónde:
 = Probabilidad de ocurrencia de uno de los casos
 = Número de aciertos en la muestra de la probabilidad
 = Número de muestras (beneficios analizados de la Tabla)
 = Valor estadístico para la aceptación o rechazo de la hipótesis
 = Probabilidad de no ocurrencia de uno de los casos
 ⁄ = Grado de error
 = Grado de libertad
 Alcanzo un 30% de los beneficios de la muestra.
225 de 274
 Alcanzo un 100% de los beneficios de la muestra.
 Por lo tanto la es mejor que la variable .
Según el cálculo t-student se considera el valor de α de acuerdo con el número de

muestras que se tiene. En este caso, considerándose de una muestra menor a 100,
el valor es de 0.05 para hacer el cálculo del grado de error.
Para los rangos de rechazo de la hipótesis se calcula por el valor del grado de
libertad obtenido y el valor del grado de error; se busca en la tabla de t-Student y se
tienen los rangos, en este caso es de -2,2622 y 2,2622, es decir, cualquier valor
dentro de este rango demostrará que la hipótesis es nula ( ) y la aceptación
(hipótesis alternativa ) de la hipótesis se encuentra fuera de estos rangos
Entonces
Entonces
| |
226 de 274
Figura 90: Campana de Gauss para la aceptación de la hipótesis.
Debido a que el valor del estadístico -4,8305 está en el intervalo que corresponde a
hipótesis alternativa en la cual: se puede concluir que los procedimientos
manuales y los sistemas utilizados en la actualidad para el control de kardex,
asistencia y vacaciones tiene menores beneficios que el sistema de control de
personal aplicando la Arquitectura Orientada a Servicios integrado con dispositivo
biométrico quedando demostrado que el sistema propuesto genera más beneficios
que el sistema actualmente existente en la institución.
227 de 274
4.1. VIABILIDAD TECNICA.
Para el desarrollo del software se requieren requisitos mínimos los cuales en la

actualidad son cumplidos a cabalidad por las El Gobierno municipal autónomo de
Cochabamba.
A continuación detallaremos los requisitos mínimos e ideales para la puesta en

marcha del proyecto desde el punto de vista del cliente y de los servidores con los
que debe contar el Gobierno Municipal autónomo de Cochabamba.
Tabla 45: Tabla de requerimientos mínimos para la construcción del software

(Cliente - Servidor).
REQUERIMIENTOS REQUERIMIENTOS
CLIENTE
MÍNIMOS IDEALES
Windows Vista Profesional

Sistema operativo Windows 8
Service Pack 1
Internet Explorer 6 Internet Explorer 9
Navegador Firefox 19 Firefox 21
Chrome Chrome
Procesador Pentium I. Procesador Core i7 2.2ghz
RAM 2 GB RAM 8GB

Computador personal
Disco duro de 200 GB Disco duro de 1TB
Dispositivos Periféricos Dispositivos Periféricos
228 de 274
CLIENTE
MÍNIMOS IDEALES
Digital Persona U.are.U Digital Persona U.are.U

Lector Biométrico
4000b con SDK para C# 4000b con SDK para C#
SERVIDOR
MÍNIMOS IDEALES
Procesador Intel® Xeon® Procesador Intel® Xeon®

Quad-Core de 1.8 Ghz Quad-Core de 2.2 Ghz
Equipo dedicado servidor
RAM 4 GB RAM 8 GB
Disco duro 16TB Disco Duro 32 TB
Sistema Operativo Windows Server 2008 Windows Server 2012
Internet Information Internet Information
Server 6 Server 8
Servicios web asp.net. Servicios web asp.net

Servicios
Oracle 10g Edition. Oracle 12g Edition
Sql Server 2008 Enterprise Sql Server 2012 Enterprise

Edition Edition
La institución cuenta con los requerimientos mínimos en lo que se refiere a los

servidores tomando en cuenta que se necesitan servidores dedicados que se
encargaran de alojar la base de datos del sistema y el repositorio de servicios,
además de los mencionados anteriormente también se necesitan computadores para
cada uno de los funcionarios pertenecientes a la institución con acceso a la red
corporativa e internet.
229 de 274
4.2. VIABILIDAD ECONOMICA.
4.2.1. Estimación de coste del producto
El proceso de estimación del coste de un producto software está formado por un

conjunto de técnicas y procedimientos que se usan para poder llegar a una
predicción fiable.
La estimación del tamaño del software es la predicción de cuán grande será el

producto una vez que esté terminado. La principal razón para estimar el tamaño del
software es ayudar a construir un plan de desarrollo.
El modelo COCOMO es el modelo de estimación de costes más utilizado con el cual

se estima el “esfuerzo” para desarrollar, en este caso, el proyecto de Trabajo de
Grado.
La estimación de costos es una aproximación a los costos del proyecto. Se mide en

términos de esfuerzos requeridos por persona/mes por año.
COCOMO hace referencia a tres modos de desarrollo del proyecto, influyen

directamente en la duración y costo del mismo:
 Orgánico: equipos de soft relativamente pequeños desarrollando soft muy

familiar en un ambiente “hogareño”.
 Embebido: opera con limitaciones estrechas, el producto está fuertemente

atado a hardware complejo, regulaciones de soft y procedimientos
operacionales.
 Semi-aislado: paso intermedio entre los dos anteriores. Usualmente con 300
KDSI.
230 de 274
Tabla 46: Valores constantes por modo de desarrollo
MODO DE
A B C D
DESARROLLO
ORGÁNICO 3,2 1,05 2,5 0,38
EMPOTRADO 3 1,12 2,5 0,35
SEMIACOPLADO 2,8 1,2 2,5 0,32
El modelo orgánico será utilizado en el presente Trabajo de Grado, porque se

considera que el desenvolvimiento del proyecto ha sido desarrollado sobre un
ambiente cálido de trabajo (familiar).
COCOMO está definido en términos de tres modelos diferentes: modelo básico,

intermedio y detallado, que reflejan el nivel de detalle considerado a la hora de
realizar la estimación del coste. Según la teoría, el modelo intermedio y el detallado,
usan un “Factor de Ajuste del Esfuerzo” (EAF).
Tabla 47: Ecuación básica del esfuerzo en COCOMO (Modelo Intermedio y

Detallado).
MODO DE
ECUACIÓN BÁSICA DEL ESFUERZO
DESARROLLO
ORGÁNICO
EMPOTRADO
SEMIACOPLADO
Fuente: Jesús Álvares Sáez.
231 de 274
Tabla 48: Ecuación básica del tiempo en COCOMO (Modelo Intermedio).
ECUACIÓN BÁSICA
MODO DE
DESARROLLO DEL ESFUERZO
ORGÁNICO
EMPOTRADO
SEMIACOPLADO
Según la tabla 40 y la tabla 41, la ecuación del Esfuerzo y del Tiempo de Desarrollo
que se utilizará será el del Modo de Desarrollo Orgánico, a continuación se describen
las variables y sus unidades:
[ ]
[ ]
Este modelo intermedio obtiene mejores resultados, porque establece 15 factores de

costo, que determinan la duración y el coste del proyecto.
232 de 274
Tabla 49: Factores de Costo en COCOMO.
FACTORES DE MUY MUY EXTRA

BAJO MEDIO ALTO
COSTO BAJO ALTO ALTO
ATRIBUTOS DEL
Fiabilidad Requerida del

RELY 0,75 0,88 1 1,15 1,4 -
Software
PRODUCTO
Tamaño de la Base de
DATA - 0,94 1 1,08 1,16 -
Datos
Complejidad del
CPLX 0,7 0,85 1 1,15 1,3 1,65
Producto
Restricciones del
TIME - - 1 1,11 1,3 1,66
Tiempo de Ejecución
ATRIBUTOS DEL
COMPUTADOR
Restricciones del
Almacenamiento STOR - - 1 1,06 1,21 1,56
Principal
Volatilidad de la
VIRT - 0,87 1 1,15 1,3 -
Máquina Virtual
Tiempo de respuesta
TURN - 0,87 1 1,07 1,15 -
del ordenador
ATRIBUTOS DEL PERSONAL
Capacidad del Analista ACAP 1,46 1,19 1 0,86 0,71 -
Experiencia en
AEXP 1,29 1,13 1 0,91 0,82 -
Aplicaciones
Capacidad de los
PCAP 1,42 1,17 1 0,86 0,7 -
programadores
Experiencia en Sistema
VEXP 1,21 1,1 1 0,9 - -
Operativo utilizado
Experiencia con el
Lenguaje de LEXP 1,14 1,07 1 0,95 - -
Programación
Prácticas de
ATRIBUTOS DEL
MODP 1,24 1,1 1 0,91 0,82 -

programación modernas
PROYECTO
Utilización de
Herramientas de TOOL 1,24 1,1 1 0,91 0,83 -
Software
Limitaciones de
planificación del SCED 1,23 1,08 1 1,04 1,1 -
desarrollo del proyecto
233 de 274
Nota. Los valores marcados con fondo verde, se consideran seleccionados para la
estimación de costos. La justificación de cada valor seleccionado se detalla en el
Anexo E. Tabla de Justificaciones.
En la tabla 45, se ha seleccionado los valores para cada uno de los 15 factores de
costos, los cuales se multiplicarán y se obtendrán el valor del EAF.
Para determinar la cantidad total de líneas de código fuente se ha empleado la

herramienta de Visual Studio 2010 cálculo de métricas de código, con el cual, se ha
obtenido un total de líneas de 3025 líneas de código fuente (SLOC).
Para determinar el valor de la variable KSLOC se van a usar unidades de SLOC

(Líneas de código fuente), con las siguientes restricciones: Sumar las líneas de
código creadas por el personal del proyecto (no el creado por generadores de
aplicaciones). Se considera que una instrucción es una línea de código. Las
declaraciones se toman como instrucciones. Los comentarios no se cuentan como
instrucciones.
Según la figura anterior solo se sumarán los valores de la columna “Code Lines” sin
tomar los valores de la cantidad de líneas comentadas y líneas vacías (cumpliendo
con las restricciones establecidas anteriormente), se determina que:
Entonces, una vez encontrados los valores de EAF y KSLOC, se procede a calcular
el esfuerzo:
234 de 274
[ ]
Obtenido el valor del Esfuerzo se procede a calcular el Tiempo de Desarrollo:
[ ]
Ahora se procede a calcular el “Personal Promedio” requerido para desarrollar el

proyecto:
[ ]
Ahora se calcula la “Productividad”;
[ ]
Interpretando los valores obtenidos, se determina que para el proyecto se ha escrito

3025 líneas de código, lo que se traduce en un esfuerzo de 10 personas por mes, el
proyecto se ha desarrollado en 6 meses y, lo ideal para desarrollar el proyecto es,
contar con 1 programador.
El desarrollador ha trabajado tres horas al día (por motivos de estudio), quien ha

realizado las tareas de análisis, diseño y codificación del proyecto. Se ha
considerado el trabajo en días laborales de lunes a viernes, tres horas al día, lo que
235 de 274
supone unas 60 horas al mes. Y según el tiempo estimado multiplicado por la
cantidad de horas al mes, se obtiene un total de horas de trabajo de 324 horas.
[ ]
Para determinar una aproximación del costo de desarrollo del proyecto se ha

averiguado que el sueldo para el área de programación en Bolivia oscila el valor de
35 Bs la hora. Tomando en cuenta que en las instituciones, trabajan de lunes a
viernes durante un mes (con cuatro semanas) por el lapso de ocho horas diarias.
Por tanto, ajustando el horario de trabajo del autor del proyecto (3 horas al día), y
considerando el pago por hora de 35 Bs. Se procede a calcular el costo estimado del
proyecto, multiplicando la cantidad de horas a trabajar en el lapso de tiempo
estimado por el pago por hora determinado según el horario de la institución:
[ ] [ ] [ ]
Observando el resultado de la ecuación se determina que el costo estimado del

proyecto es de 11340 Bolivianos.
De ésta manera, se ha empleado el método de estimación de costos COCOMO,

calculando los valores para medir el esfuerzo (E), cantidad de líneas de código
fuente (KSLOC), el ajuste de los factores de esfuerzo (EAF) y el tiempo para el
desarrollo del proyecto, determinando así que el costo estimado de desarrollo del
proyecto es de 11340 Bolivianos, considerando que el proyecto ha sido desarrollado
por una sola persona. Considerando el esfuerzo y la magnitud del proyecto, se
considera que el proyecto es viable económicamente.
4.2.2. Estimación de gastos en Software y Hardware
Para la implementación del proyecto y al constituirse este en un aplicando la

arquitectura orientada a servicios se debe tomar en cuenta que existe un servidores
236 de 274
dedicados para la base de datos y para el repositorio de servicios, tomando en
cuenta lo explicado anteriormente, se muestra la tabla 43 un estimado de los costos
de software y hardware para la implementación del sistema de control de personal
aplicando la arquitectura orientada a servicios.
Tabla 50: Estimado de coste de software y hardware
PRECIO
SOFTWARE CARACTERÍSTICAS CANTIDAD UNITARIO TOTAL
($US)
Licencia de SQL Versión Enterprise 1 140 140

Server 2008
Licencia de Home Premium de 32 1 150 150

Windows vista Bits
professional
Licencia de Visual Professional 1 350 350

Studio 2010
Internet Ilimitado 9 50 450
Licencia de Oracle Standard Edition One 1 4995 4995

10g
Licencia de windows R2 Datacenter 1 2099 2099

server 2008
237 de 274
PRECIO
HARDWARE CARACTERISTICAS CANTIDAD UNITARIO TOTAL
($US)
Servidor NAS marca Procesador Intel® 1 2597 2597

Dell Xeon® Quad-Core de
2.2 Ghz
RAM 8 GB
Disco Duro 32 TB
Lector biométrico Digital Persona U.are.U 1 85 85

4000b con SDK para
C#
Total general en 10866

dólares
Total general en 75627,36

bolivianos
En base al costo total considerando los requerimientos mínimos de hardware y

software el cual es de 75627,36 Bs., se puede mencionar que la institución posee
algunos de los requerimientos establecidos para este proyecto, por lo cual el costo
total se reduce a 18666,70 Bs. A continuación se muestra la tabla en la que se
indican los requerimientos que posee la institución con un costo de 0 Bs.
238 de 274
Tabla 51: Costos de requerimientos para la institución.
ESTADO DEL PRECIO

SOFTWARE UNITARIO TOTAL
REQUERIMIENTO ($US)
Licencia de SQL
Si 140 0
Server 2008
Licencia de
Windows vista Si 150 0
professional
Licencia de Visual
Si 350 0
Studio 2010
Internet Si 50 0
Licencia de Oracle
Si 4995 0
10g
Licencia de
Windows server Si 2009 0
2008
239 de 274
ESTADO DEL PRECIO
HARDWARE UNITARIO TOTAL
REQUERIMIENTO ($US)
Servidor NAS marca Si 2597 0

Dell
Lector biométrico No 85 85
Total general en 85
dólares
Total general en 591,6

bolivianos
El monto que se requiere para la implementación del sistema será finalmente de

591,6 Bs., más el costo de desarrollo del sistema Bs. dando un total de
11931,6 Bs., en base a que el monto de inversión es considerable, a continuación se
realizará un análisis de comparación de beneficios y costos, para determinar la
viabilidad económica del proyecto.
4.2.3. Análisis beneficio-costo.
Para realizar el análisis de beneficio – costo del presente proyecto se emplearán los
siguientes datos:
 Cinco años, es el tiempo de vida útil del proyecto.

 2,31% es la tasa de interés anual. (Fuente: BNB).
 Inversión inicial de 11931,60 Bs.
Teniendo en cuenta estos resultados podemos mencionar algunos beneficios

otorgados por el sistema, como ser:
240 de 274
A continuación se determina el análisis Beneficio/Costo detalladamente.
Tabla 52: Detalle de los costos.
MONTO SIN MONTO POSIBLE

DETALLE
SISTEMA CON SISTEMA
Planillas de asistencia. 104,32 Bs.- 31,30 Bs.-
Planillas de vacaciones 104,32 Bs.- 31,30 Bs.-
Planillas de permisos. 104,32 Bs.- 31,30 Bs.-
Boletas de permisos. 250 Bs.- 0 Bs.-
Boletas de vacaciones 200 Bs.- 0 Bs.-
Costo de fotocopias 1841,76 Bs.- 552,53 Bs.-
Tinta negra y de color 2622,96 Bs.- 786,89 Bs.-
Costo de elaboración de reportes de kardex. 1749,60 Bs.- 166.66 Bs.-
Costo de elaboración de reportes de asistencia. 787,68 Bs.- 166.66 Bs.-
Costo de elaboración de reportes de

393,84 Bs.- 166.66 Bs.-
vacaciones.
MONTO TOTAL ANUAL 8158,80 Bs.- 1933,32 Bs.-
241 de 274
Para el cálculo de la estimación Costo/Beneficio se tiene:
(5 años es el ciclo de vida de la

aplicación ya que se mencionó en el capítulo de generalidades, donde se
determinó el alcance temporal).
Yn = 8158.80 – 1933.32
Yn = 6225,48 Bs.
Al obtener el resultado mayor a 1 se puede concluir que los beneficios que se

obtienen con la implantación del proyecto son justificables respecto al costo invertido
para su desarrollo, por lo tanto el proyecto es económicamente viable y beneficiara al
gobierno municipal autónomo de Cochabamba.
242 de 274
4.3. VIABILIDAD OPERATIVA.
La viabilidad operativa se demuestra mediante la aplicabilidad e importancia que

supone la implantación del sistema de control de personal aplicando la arquitectura
orientada a servicios y la aceptación del personal implicado en este proceso.
Para el desarrollo de este sistema, se divide al personal de acuerdo a las funciones

que cumplen estos se encuentran denominados como roles los cuales son:
Administrador del sistema, Encargado de Recursos humanos y Funcionario.
1) El Administrador del sistema del sistema.

2) Es aquel usuario que se encarga de la administración de los usuarios y puede
generar reportes para realizar estadísticas de los usuarios del sistema.
Deberá presentar el siguiente perfil:
 Nivel de estudios: Técnico medio o superior en programación, Licenciado
en informática o Ingeniero de sistemas, conocimiento en redes y
telecomunicaciones.
 Requisitos mínimos: Analista de sistemas, técnico en redes y
programador con experiencia mínima de un año en las siguientes
tecnologías:
 SQL Server 2008 o 2012 (Requerido).
 Windows Server 2008 Data Center o posterior (Requerido).
 Oracle 10g o versiones posteriores (Requerido).
 C# Windows Forms (Requerido).
 ASP.net Framework 3.5 o superior (Requerido).
 Ingles nivel medio (Deseable).
3) El Encargado de Recursos humanos es el encargado de registrar toda la
información correspondiente a los datos de kardex, asistencia y vacaciones,
además esta persona puede generar reportes de los tres subsistemas integrados:
 Nivel de estudios: bachiller en humanidades, Operador de
computadores.
243 de 274
 Requisitos mínimos: 2 años de experiencia laboral en la empresa.
 Experiencia en manejo de dispositivo bimétrico (Requerido).
4) El Funcionario deberá cumplir con los siguientes requerimientos:
 Nivel de estudios: bachiller en humanidades.
 Requisitos mínimos: Conocimiento y manejo básico de navegadores de
internet.
Las interfaces para el usuario se encuentran desarrolladas en base a la facilidad de

comprensión, aprendizaje y uso, el objeto de interés por parte del usuario es de fácil
identificación, cuenta con iconos de fácil acceso. Las interacciones se basan en
acciones físicas sobre elementos del código visual y en selecciones de tipo menú
con sintaxis y ordenes, se tiene operaciones que son rápidas, con efectos inmediatos
y un tratamiento del error bien cuidado y adecuado al nivel de usuario.
El sistema permite el registro de usuarios, asignando a cada uno un rol de acuerdo a

la función que cumple en la institución, se realiza el registro de los datos del kardex
de los funcionarios, el control de asistencia respectivo utilizando el dispositivo
biométrico integrado así mismo el control de las vacaciones.
El sistema permite la generación de reportes que son mostrados en pantalla y a su

vez pueden ser exportados en formatos PDF y Excel, con la opción de ser impresos
según así lo desee el usuario, los tipos de reportes serán generados de acuerdo a
rangos de fechas, tipos de usuarios, operaciones realizadas por los usuarios y
reportes generales diarios para el administrador del sistema que son utilizados para
generar estadísticas.
Para que los usuarios puedan dar un adecuado manejo al sistema se realizará un
curso de capacitación básica, dando a conocer las funcionalidades del sistema y
como acceder a dichas funcionalidades.
244 de 274
5.1. CONCLUSIONES.
El presente proyecto de grado ha permitido analizar, evaluar, construir y aplicar un

sistema de control de personal aplicando la arquitectura orientada a servicios
integrado con dispositivo biométrico, a continuación se describen las conclusiones
que se obtuvieron para cada objetivo específico:
 En base a las entrevistas y la observación realizados al personal involucrado

en el proceso de kardex, subsistema de asistencia y subsistema de
vacaciones dentro de la institución, se ha podido identificar las actividades que
se llevan a cabo de manera ineficiente y determinar su causa principal la cual
consiste en el retardo en el procesamiento de la información, posibilidad de
cometer errores en el proceso de transcripción a planillas oficiales, molestia
por parte del personal, tareas repetitivas y duplicadas, incumplimiento del
reglamento interno de personal y de la Ley General del Trabajo. Todo el flujo
existente se reflejó en un modelo de negocio actual en el cual se muestra
gráficamente como se realiza todo el trabajo con los 2 sistemas antes
mencionados.
 En base a las deficiencias encontradas se elaboró una propuesta de diseño de

procedimientos alternativos, considerando las oportunidades que brinda un
sistema web con la aplicación de la arquitectura orientada a servicios
integrado con dispositivo biométrico (facilidades más adecuadas y actuales),
con el objetivo de conseguir un proceso eficiente, en cuanto a la reducción del
tiempo invertido en el proceso de control de asistencia e identificación de los
funcionarios públicos, disminución de los errores en la elaboración de los
reportes respectivos y obtener reportes clasificados para información. Todos
estos beneficios se consiguen según el modelado alternativo mediante el
desarrollo de un sistema web que permitirá la integración de los subsistemas
de kardex, asistencia y vacaciones, mediante la aplicación de la arquitectura
orientada a servicios, integrado con dispositivo biométrico. Adicionalmente se
han analizado distintos procesos de desarrollo de software, como resultado
245 de 274
del análisis se tomó la decisión de enfrentar el desarrollo del proyecto
aplicando el modelo incremental planificándolo como una serie de incrementos
lo cual ha permitido entregar productos operacionales a los usuarios finales en
cada incremento y obtener la retroalimentación oportuna para realizar cambios
requeridos e implementación de nuevas funcionalidades
 Inicialmente se ha desarrollado el subsistema de kardex que incluye las

cuentas de usuario con lo que se consiguió que el acceso al sistema sea
únicamente para usuarios autorizados y se garantiza la confidencialidad e
integridad de información, en este módulo el encargado de recursos humanos
puede realizar la administración del kardex. Para lograr este subsistema se
emplearon: el IDE Visual Studio con el lenguaje de programación C# y el
gestor de base de datos Oracle los cuales fueron seleccionados porque
brindan los siguientes beneficios, en el caso de c# porque trabaja en un
entorno rápido, fácil de manejar y de fácil aprendizaje y Oracle fue
seleccionado por la seguridad que brinda, capacidad de almacenamiento y
fácil manejo de consultas. Una vez culminado el subsistema se realizaron
pruebas funcionales que permitieron evaluar los errores existentes, corregirlos
y entregar un producto libre de errores.
 El subsistema de asistencia que incluye los módulos de registro de asistencia

y verificación de asistencia, permite registrar la asistencia de los funcionarios
de la institución en base al horario establecido para cada uno de ellos, en este
subsistema también se desarrolló el módulo de registro de permisos para los
funcionarios de la institución, en el cual se registran tres tipos de permisos los
cuales son: Permiso de maternidad, permiso por accidente laboral y permiso
por enfermedad (VER ANEXO C) y en base a la solicitud realizada por el
funcionario vía web el encargado de recursos humanos realiza la aceptación o
rechazo de la misma. Una vez terminado el subsistema se realizaron pruebas
funcionales que permitieron determinar la existencia de errores, subsanarlos
para posteriormente entregar un producto confiable.
246 de 274
 El subsistema de vacaciones permite al encargado de recursos humanos
realizar el registro y administración de las vacaciones de los funcionarios
pertenecientes a la institución, en base a la información registrada podrá
realizar el control de las vacaciones para cada funcionario y de esta manera
pueda obtener la información de la cantidad de días de vacación disponibles.
Luego de haber concluido el desarrollo del subsistema se realizaron pruebas
funcionales que permitieron evaluar los errores existentes, corregirlos y
entregar un producto sin errores.
 Para realizar la integración con el dispositivo biométrico, se modificó el

marcado de asistencia a huella dactilar, esto facilita el marcado de ingreso y
salidas de la institución de los funcionarios públicos brindando seguridad y
evitando la suplantación de identidad, al integrar con el sistema de control de
personal se obtendrá de manera rápida y sencilla los reportes de asistencia.
 La generación y exportación de reportes se realizó de acuerdo a los

requerimientos de la institución, este módulo desarrollado permite exportar los
reportes a diferentes extensiones como ser: Excel, PDF y Word, lo que
permite a la institución contar con respaldo de documentación, y generar
estadísticas a partir de estos reportes, se ha empleado Crystal Reports por la
facilidad que brinda al crear e integrar informes interactivos con la plataforma
.NET.
 Las pruebas que se realizaron en el sistema completo fueron las pruebas de

unidad que permitieron identificar la presencia de los errores en base al
aislamiento de partes del código y en base a esto se pudo evidenciar las
falencias existentes en los diferentes servicios y realizar su respectiva
corrección. Así mismo las pruebas de integración se realizaron de manera
implícita ya que al existir en la Arquitectura Orientada a Servicios, una
estructura de servicios web que realizan la integración explicita de los
servicios mediante los protocolos (XML, SOAP, WDSL, UDDI), permitieron
247 de 274
verificar la intercomunicación entre los diferentes servicios pertenecientes a
diferentes subsistemas y de esta manera garantizar un producto final robusto
y confiable.
Por otra parte, se ha demostrado que el nivel de complejidad en el uso del sistema
de control de personal es de complejidad media para los funcionarios lo cual
garantiza su implementación adecuada en la institución realizando el curso de
capacitación mencionado anteriormente.
De ésta manera, se considera que, se han alcanzado los objetivos trazados en el

presente proyecto, puesto que, se ha dado solución al problema identificado,
brindando una propuesta que mejora el proceso de control del personal, dentro del
gobierno municipal autónomo de Cochabamba.
5.2. RECOMENDACIONES.
Al momento de puesta en marcha del sistema desarrollado, se recomienda:
 Verificar que el sistema operativo del servidor cuente con el servidor IIS para
proveer servicios http y el Framework 3.5 de .NET; además del
funcionamiento del sistema de control de acceso biométrico y realizar
mantenimiento a la base de datos, software y hardware correspondientes,
debido a que este proporciona los registros de ingreso y salida, en los que se
basa el procesamiento de gestión de personal y el funcionamiento irregular de
este reflejara inconsistencia o falta de veracidad en los reportes de asistencia
generados.
 Verificar que el dispositivo biométrico, esté en red y se pueda garantizar la

comunicación con el servidor de Base de Datos, para lo cual se recomienda
utilizar alguna tecnología de comunicación y redes, como ser: Redes Privadas
Virtuales, u otras. Además configurar el motor de Base de Datos bajo los
protocolos TCP/IP.
248 de 274
 Al incorporar la integración de otro sistema a través de la Arquitectura
Orientada a Servicios, se debe verificar inicialmente que la plataforma de
desarrollo utilizada tenga soporte para Servicios, de otra forma no se podrá
realizar la integración a nivel de software y se tendrá que utilizar servicios
locales o interacciones continuas con la base de datos, ya que a pesar de que
la gran mayoría de las plataformas de programación de la actualidad tienen
soporte orientado a servicios, no todas la tienen y las tecnologías antiguas
tampoco tienen dicho soporte, sin embargo se recomienda emplear medios de
intercambio de mensajes de texto mediante parseadores para poder realizar la
interacción con otros sistemas desarrollados en dichas plataformas de
desarrollo antiguas.
 Para la implementación del sistema de control de personal la institución debe

contar con computadores para cada funcionario, equipado con navegadores
como ser Opera, Chrome, Internet explores o Mozilla Firefox.
 Para el funcionamiento del sistema se requiere un servidor único de la

empresa para asegurar la información y así poder evitar fraudes futuros.
 Que la red corporativa este correctamente configurada y funcionando a nivel

LAN para permitir la comunicación interna y a nivel WAN, para la conexión a
Internet, para que los usuarios puedan enviar mensajes al administrador de
posibles errores que puedan ocurrir al momento de hacer uso del sistema.
Recomendaciones a futuro:
 Con el propósito de mejorar el control de asistencia se recomienda adquirir

nuevos dispositivos biométricos que permitan agilizar el reconocimiento de los
funcionarios mediante la implementación de lectores faciales, al momento de
registrar los ingresos y salidas.
249 de 274
 La Arquitectura Orientada a Servicios permite que el sistema de control de
personal pueda interoperar con diferentes servicios, que además pueden ser
de plataformas diferentes que tengan soporte para servicios. Por lo tanto se
puede incorporar servicios que permitan la integración con los diferentes
sistemas existentes en la institución como ser el sistema de contabilidad, que
permitirá reducir el tiempo de espera de los funcionarios públicos y la no
duplicación de datos en los servidores.
 En base a la innovación tecnológica de los últimos tiempos es recomendable

emplear aplicaciones móviles que permitan el envío de la información de
estado de permisos y ver reportes de asistencia para un funcionario.
250 de 274
BIBLIOGRAFÍA
Accesor. (2014). Lecctores Biometria. Obtenido de

http://www.accesor.com/esp/art2_query.php?fam=3&sfam=4
BearSoft. (2014). ARQUITECTURA ORIENTADA A SERVICIOS. Obtenido de

http://www.bearsoft.com.bo/contenido/soa.jsp?pag=6e
Biometricsid. (2013). Control de Asistencia de Personal, Control de Acceso, Relojes

Biométricos y Desarrollo de Software. Obtenido de
http://www.biometricsid.com.ec/nosotros.html
Codisa. (2014). CODISA QUERY BUILDER. Obtenido de

http://www.codisa.com/herramientas-query-builder.html
Corporation, M. (2006). La Arquitectura Orientada a Servicios (SOA) de Microsoft.
Delgado, A., González, L., & Piedrabuena, F. (2003). Desarrollo de aplicaciones con
enfoque SOA. Montevideo, Uruguay: Universidad de la República.
E. Kendall, K., & E. Kendall, J. (2005). Análisis y diseño de sistemas. Sexta edición.
Mexico: Pearson Education.
Eclipse. (2014). Acerca de Eclipse. Obtenido de https://www.eclipse.org/org/#about
Florentino López, L. (s.f.). NetBeans 7.4 IDE completo paraProgramación Orientada

a Objetos. Obtenido de http://tnt95.blogspot.com/2013/11/netbeans-74-ide-
completo.html
González Seco, J. A. (2001). El lenguaje de programación C#. España: Universidad

de Murcia.
Holzner, S. (2000). La biblia de Java 2. Madrid: Anaya.
Internet, I. S. (2013). Identificación biométrica. Obtenido de

http://www.instisec.com/publico/impresora.asp?seccion=4&id=20
251 de 274
Jacobson, I., Booch, G., & Rumbaugh, J. (2000). El Proceso Unificado de Desarrollo
de Software. Madrid: Pearson Educacion S.A.
JIbarra. (2014). Introducción a los servicios web: SOA. Obtenido de

http://blog.theinit.com/2011/09/22/introduccion-al-soa/
libres, A. (2014). Alternativas para Crystal Reports. Obtenido de

http://freealts.com/privapp.php?id=185
Mabrouk, M. (2008). SOA fundamentals in a nutshell. IBM.
Microsoft. (2014). Plataformas y Servidores de la nube. Obtenido de

http://www.microsoft.com/en-us/server-cloud/products/sql-
server/#fbid=eKXwkZM56WM
Microsoft Corporation. (2006). La Arquitectura Orientada a Servicios (SOA) de

Microsoft. La arquitectura SOA de Microsoft® aplicada al mundo real, 20.
MySQL. (2014). Panorámica del sistema de gestión de base de datos MySQL.

Obtenido de https://dev.mysql.com/doc/refman/5.0/es/what-is.html
Network, D. (2014). Crystal Reports. Obtenido de http://msdn.microsoft.com/es-

es/library/bb126227(v=vs.90).aspx
Network, D. (2014). Crystal Reports. Obtenido de http://msdn.microsoft.com/es-

es/library/bb126227(v=vs.90).aspx
ORACLE. (2014). ORACLE DATABASE 10G. ORACLE.
Perdonomo, E., Zamora Pérez, C. L., & Ramírez, J. E. (2009). GUÍA DE

APRENDIZAJE Nº 4 LA RECOLECCIÓN DE INFORMACIÓN. Huila: Neiva.
php. (2014). Manual de PHP. Obtenido de http://www.php.net/manual/es/features.php
S. Pressman, R. (2010). INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO.

Séptima edición. México, D. F.: The McGraw-Hill Companies, Inc.
252 de 274
Sæther Bakken, S., Aulbach, A., Schmid, E., Winstead, J., Torben Wilson, L., Lerdorf,
R., . . . Ahto, J. (2002). Manual de PHP. Free Software Foundation.
Serratosa, F. (s.f.). La biometría para la identificación de las personas. ESpaña:

Fundación para la Universitat Oberta de Catalunya.
Studio, V. (2014). Desarrollo de aplicaciones. Obtenido de

http://www.visualstudio.com/es-es/explore/application-development-vs.aspx
Travieso González, C. M., del Pozo Baños, M., & Ticay Rivas, J. R. (2011). Cuaderno
Red de Cátedras Telefónica: Sistemas Biométricos. España: Universidad de
Las Palmas de.
Ureña Almagro, C. (2011). Lenguajes de Programación.
uva. (2014). JAVA. Obtenido de http://www.infor.uva.es/~jmrr/tgp/java/JAVA.html
W3C. (2014). Guía Breve de Servicios Web. Obtenido de

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
253 de 274
ANEXO A
LISTA DE REQUISITOS PARA EL KARDEX.
254 de 274
ANEXO B
LEY DEL TRABAJO
Art. 46.- La jornada efectiva de trabajo no excederá de 8 horas por día y de 48 por
semana. La jornada de trabajo nocturno no excederá de 7 horas, entendiéndose
trabajo nocturno el que se practica entre horas 20 y 6 de la mañana. Se exceptúa de
ésta disposición el trabajo de las empresas periodísticas, que están sometidas a
reglamentación especial. La jornada para mujeres y menores de 18 años, excederá
de 40 horas semanales diurnos.
255 de 274
ANEXO C
REGLAMENTO INTERNO DE PERSONAL
TITULO I
DEL CONTRATO Y LAS CONDICIONES DE TRABAJO
CAPITULO I
DEL CONTRATO DE TRABAJO
Artículo 11. (CONTRATO DE TRABAJO)-----------------------------------------------------------
Toda persona para ingresar a trabajar en la institución, deberá cumplir

satisfactoriamente con los procesos de evaluación y selección establecidos por el
Sub-sistema de Dotación de Personal, para posteriormente, procesar el contrato de
trabajo con las cláusulas respectivas y de acuerdo a las modalidades que se
establecen en el presente Reglamento.-----------------------------------------------------------
Artículo 12. (PERIODO DE PRUEBA)----------------------------------------------------------------
Toda persona que sea contratada por la institución, estará sujeta al período de
prueba de 89 días calendario, establecido por disposiciones legales, durante el cual,
se efectuarán las evaluaciones correspondientes. Dentro del período de prueba y
antes de los quince días de su conclusión , el jefe inmediato superior bajo
responsabilidad funcionaria, deberá enviar un informe a la Dirección Administrativa y
de Recursos Humanos, en el que se evaluará su desempeño y se recomendará la
contratación permanente o no de la persona sujeta al período de prueba. ----------------
De resolverse la contratación en forma indefinida, se comunicará al postulante esta

decisión por medio de un memorándum, aprobado y firmado por la Máxima Autoridad
Ejecutiva.-------------------------------------
256 de 274
Artículo 13. (MODALIDADES)--------------------------------------------------------------------------
-------------------------
La institución podrá contratar el personal requerido de acuerdo con las disposiciones

legales en vigencia en cualquiera de las modalidades siguientes:---------------------------
a. Contrato indefinido.------------------------------------------------------------------------------------
b. Contrato a plazo fijo.-----------------------------------------------------------------------------------
Artículo 14. (CONTRATO POR TIEMPO INDEFINIDO)-----------------------------------------
Comprende la contratación de la persona que reúne los requisitos exigidos por la

institución, para ocupar el cargo como servidor público, una vez que ha cumplido
satisfactoriamente el período de prueba y ha sido ratificado por la máxima autoridad
ejecutiva.----------------------------------------------------------------------------
Artículo 15. (CONTRATO A PLAZO FIJO)----------------------------------------------------------
Comprende la contratación de una persona para la realización de una labor

específica, no propia ni permanente de la institución por un plazo no mayor a un año
y bajo las regulaciones específicas estipuladas en el contrato, con supervisión de
funciones para fines del pago o remuneración.-------------------
A la conclusión del contrato no corresponde el pago del desahucio ni indemnización.-
De acuerdo a la Ley General del Trabajo, no podrá ser renovado por más de dos
veces ni operará tácita reconducción, su duración no podrá exceder de un año.--------
Artículo 16. (EXCLUSIÓN)------------------------------------------------------------------------------

----------------------------
Las diferentes clases de contratos señalados en este capítulo, son excluyentes entre
sí y no podrán acordarse simultáneamente.--------------------------------------------------------
257 de 274
Artículo 17. (INCOMPATIBILIDADES)---------------------------------------------------------------
No podrá contratarse bajo ninguna de las modalidades de contratación señaladas en

los artículos anteriores, a las personas que se encuentren comprendidas en las
siguientes incompatibilidades:------------
a. Tener parentesco hasta el tercer grado de consanguinidad y el segundo de

afinidad con servidores públicos de la institución y personal jerárquico.--------------------
b. Cuando dos personas que prestan servicios en la institución y contraigan

matrimonio entre sí, sin importar el tipo de contrato al que se hallan sujetos, el
funcionario más nuevo será retirado con goce de beneficios sociales, salvo convenio
entre los contrayentes.----------------------------------------------------
c. Tengan representación de empresas privadas, tanto nacionales como extranjeras

que contraten o tengan relación económica con la institución o el Estado. ---------------
c. Se encuentren prestando servicios en otra entidad pública o privada, excepto en

los casos de la docencia universitaria, siempre que exista compatibilidad en el
horario.----------------------------------------
d. Hayan sido destituidas anteriormente de la institución por procesos internos

debidamente ejecutoriados.-----------------------------------------------------------------------------
e. Tengan juicios o sentencias ejecutoriadas pendientes de cumplimiento con la

institución o el Estado.---
f. Se encuentren gozando de renta de vejez, salvo necesidad institucional

debidamente justificada, a través de la resolución correspondiente y por tiempo
determinado y su fuente de pago no sea el
Tesoro General de la Nación en aplicación a las normas del Código de Seguridad

Social vigente para el Sistema de Reparto.---------------------------------------------------------
258 de 274
Artículo 18. (AÑOS DE SERVICIO)-------------------------------------------------------------------
Los años de servicio de los servidores públicos son reconocidos en todo el Sector
Público, su calificación sirve para el cálculo del bono de antigüedad y vacaciones.-----
TITULO II
DEL REGIMEN DE ASISTENCIA
CAPITULO I
DE LA JORNADA DE TRABAJO
Artículo 21. (DEFINICIÓN)------------------------------------------------------------------------------

--------------------------
Jornada de trabajo efectiva es el tiempo durante el cual el personal permanece a

disposición de la institución, en el sitio donde debe desempeñar o ejercitar sus
funciones específicas.---------------------------
Artículo 22. (DURACIÓN)--------------------------------------------------------------------------------
La jornada de trabajo no excederá de 8 horas por día y de 48 por semana. La

jornada de trabajo nocturna no excederá de 7 horas, entendiéndose por trabajo
nocturno el que se practica entre horas veinte y seis de la mañana. La jornada de
mujeres no excederá de 40 horas semanales diurnas, conforme al art. 46 de la
Ley General del Trabajo.---------------------------------------------------------------------------------
Artículo 23. (HORARIO)----------------------------------------------------------------------------------
Los horarios de trabajo, serán establecidos por la institución de acuerdo a sus

requerimientos y necesidades, lo estipulado en la Ley General del Trabajo y otras
disposiciones legales correspondientes.---
259 de 274
Artículo 24. (MULTAS POR ATRASOS Y FALTAS)----------------------------------------------
Las multas por atrasos y faltas disciplinarias, se impondrán de manera automática y

sin necesidad de proceso interno, conforme a la escala siguiente:--------------------------
a. Tolerancia------------------------------------------------------------------------------------------------
- De 1 a 5 minutos por día
b. Atrasos a partir de horas 8:06 a.m. y 14:36 p.m., se computa por el tiempo
transcurrido:---------
Nro. de retrasos al Mes Rango de Tiempo Se entiende como inasistencia de: ----------
5 6-15 Min. 1 día
7 6-15 Min. 2 días
2 16-30 Min. 1 día
3 16-30 Min. 2 días
1 31-45 Min. 1 día
2 31-45 Min. 2 días
c. Faltas
- Medio día de falta: Un día de haber
- Un día de falta: Dos días de haber
- Dos días de falta Cuatro días de haber.
260 de 274
d. Abandonos
- El abandonar injustificadamente la oficina o el lugar de trabajo en las horas

establecidas por la institución, sin la respectiva autorización escrita, será considerado
como falta de medio día.---------------------------
- La persona contratada a plazo fijo o en forma eventual que sobrepase los límites de
flexibilidad en el horario de ingreso o falte injustificadamente a la jornada de trabajo,
será sancionada con el retiro o resolución del contrato de trabajo por incumplimiento
al mismo, sin derecho a reclamo posterior alguno.-----------------------------------------------
e. Los fondos retenidos por faltas, atrasos o inasistencia a la fuente de trabajo del
personal de la institución, serán transferidos y depositados en una cuenta especial a
nombre de la institución, cuya recaudación por estos conceptos será aplicada y
destinada a fomentar actividades de tipo cultural, deportivo y social en sus
respectivas reparticiones, conforme dispone expresamente el artículo segundo del
Decreto Supremo Nº 19637 de 4 de julio de 1983.------------------------------ ----------------
Artículo 25. (PERMISOS)--------------------------------------------------------------------------------
El personal de la institución no podrá abandonar sus labores durante la jornada de

trabajo, sin previa autorización del superior inmediato. Cuando en forma excepcional
se concedan permisos por motivos particulares durante la jornada de trabajo, no
podrán ser mayores a dos horas en un día y a o cho en tres meses sucesivos.---------
Para los permisos otorgados, necesariamente se utilizará la papeleta de salida,

respetando su reglamentación específica.---
Artículo 26. (OBLIGACIONES)-------------------------------------------------------------------------
Todo el personal tiene la obligación de registrar personalmente la hora de ingreso y

de salida de la institución.-------------------------------------------------------------------------------
La omisión de esta obligación se considerará como inasistencia injustificada,

quedando eximidos de esta obligación los siguientes servidores públicos:----------------
261 de 274
-Alcalde Municipal
-Asesores
-Oficial Mayor
- Oficiales de Área
-Directores de Area
-Algunos Jefes de Departamento y personal subalterno de la institución, previa

justificación, debido a la naturaleza de sus actividades.-----------------------------------------
Artículo 27. (PRECAUCIONES)------------------------------------------------------------------------
Luego de concluida la jornada de trabajo, todo el personal de la institución, deberá

dejar en completo orden y en condiciones de plena seguridad los dineros
recaudados, valores, libros, registros, se llos y demás materiales a su cargo.------------
CAPITULO III
DE LAS VACACIONES
La vacación anual, es el derecho al descanso remunerado que la ley reconoce a todo

servidor público con el cese de su trabajo habitual para la reposición de energías
fisiológicas debido al desgaste por la fuerza de trabajo, nace en el momento que ha
cumplido un año y un día en forma continua de servicios, de acuerdo a la escala
establecida en las disposiciones laborales en vigencia.----------------------------------------
Artículo 33. (PLANIFICACIÓN)-------------------------------------------------------------------------
Los directores de cada unidad, deberán presentar a la Dirección Administrativa y de

Recursos Humanos, la programación de vacaciones anual del personal que se
encuentra bajo su cargo, el mismo que deberá ser formulado en coordinación con el
262 de 274
mencionado personal, a fin de no perjudicar el normal desarrollo de las actividades
de la institución.---------------------------------------------------------------------------------
El Rol de vacaciones Anual, deberá contemplar mínimamente la programación del

uso del 50% de la vacación del servidor público, quedando el restante 50% en forma
opcional para casos de emergencia.-----
Artículo 34. (DERECHOS)-------------------------------------------------------------------------------
Los servidores públicos de la institución, tendrán derecho de hacer uso de su

vacación anual, cuando hubieran completado el año de trabajo por el cual
corresponda el beneficio, tomando en cuenta el rol de vacaciones establecido. Este
rol así formulado, se deberá dar a conocer a los servidores públicos por lo menos
con quince días de anticipación a la gestión correspondiente. -------------------------------
Dentro de los veinte días de publicado el rol de vacaciones anual, el servidor público
podrá solicitar justificadamente su modificación. Pasado dicho término, deberá ser
cumplido el programa, salvo necesidades de servicio, que deberán ser dispuestas
por la máxima autoridad ejecutiva.----------------------
En ningún caso corresponderá el pago de vacaciones en efectivo, excepto en los

casos de despido o disposición en vigencia que exprese lo contrario, su
incumplimiento será sancionado por la Ley de
Administración y Control Gubernamentales.--------------------------------------------------------
Artículo 35. (ESCALA)------------------------------------------------------------------------------------
Los días de vacación que corresponden a cada trabajador y/o servidor público, se
calcularán con base a la antigüedad en la institución y calificación de años de
servicio en el Estado de acuerdo a la siguiente escala, conforme lo previsto por el
artículo 49 de la Ley 2027 (Ley del Estatuto del Funcionario Público):----
De un año y un día hasta cinco años de antigüedad 15 días hábiles.-----------------------
263 de 274
De cinco años y un día hasta diez años de antigüedad 20 días hábiles.-------------------
De diez años y un día o más 30 días hábiles.------------------------------------------------------
Artículo 36 (OBLIGATORIEDAD)----------------------------------------------------------------------
El uso de la vacación anual es obligatoria para todos los servidores públicos de la

institución, ésta no podrá ser acumulada por más de dos períodos anuales, salvo el
caso de existir una imperio sa necesidad de acuerdo al Artículo 33 del Decreto
Reglamentario de la Ley General del Trabajo. -----------------------------
Artículo 37. (EXCEPCIONES)--------------------------------------------------------------------------
No tendrán derecho a vacaciones los servidores públicos con licencia sin goce de
haberes, por el tiempo que ésta dure.----------------------------------------------------------------
CAPITULO IV
DE LAS LICENCIAS
Licencia es la inasistencia al trabajo por medio día o períodos mayores, autorizada

por la Máxima
Autoridad Ejecutiva, el Oficial Mayor del Area o el Director de Recursos Humanos,

según amerite el motivo o justificación de la licencia.--------------------------------------------
Artículo 39. (CLASES)------------------------------------------------------------------------------------
La institución podrá conceder licencia a los servidores públicos, siempre que a su

juicio exista una razón justificada y debidamente comprobada.-------------------------------
Las licencias podrán ser:--------------------------------------------------------------------------------
a. Con goce de haber.------------------------------------------------------------------------------------
b. Sin goce de haber.-------------------------------------------------------------------------------------

264 de 274
c. Con cargo a vacación.---------------------------------------------------------------------------------
Artículo 40. (LICENCIAS CON GOCE DE HABER)----------------------------------------------
Las licencias con goce de haber, procederán en los siguientes casos:---------------------
a. Por fallecimiento del cónyuge, hijos o padres del servidor público, cinco días
calendario desde el día del fallecimiento.-----------------------------------------------------------
b. Por parto de la cónyuge, un día calendario, en el día del parto o alumbramiento.----
c. Por asistencia a cursos de capacitación o entrenamiento.----------------------------------
d. Por enfermedad y/o maternidad, conforme a lo dispuesto en el Código de

Seguridad Social.--------
e. Por matrimonio del servidor público, tres días hábiles.---------------------------------------
f. Por aniversario del servidor público, un día calendario.---------------------------------------
En todos los casos anteriores, a la culminación de la licencia, el servidor público,

deberá sustentar la licencia con el documento pertinente.--------------------------------------
Artículo 41.( LICENCIAS SIN GOCE DE HABER)------------------------------------------------
Las licencias sin goce de haber, podrán otorgarse a favor del trabajador o servidor
público municipal después de cumplido el año continuo de servicios, por causas que
a criterio de la institución sean justificadas y se concederán de acuerdo a la siguiente
modalidad:-----------------------------------------------------
a. De uno a cinco días, con autorización escrita del Director de la Unidad

correspondiente y del Director Administrativo y de Recursos Humanos.-------------------
b. De seis a catorce días, con autorización escrita del Oficial Mayor de cada área.-----
265 de 274
c. Por asuntos particulares debidamente justificados, en forma excepcional la
Máxima Autoridad Ejecutiva, podrá conceder licencia de quince a noventa días, sin
goce de haberes mediante resolución expresa.---------------------------------------------------
d. Por el tiempo de cumplimiento del Servicio Militar, conforme a Ley.---------------------
Artículo 42. (LICENCIAS CON CARGO A VACACIONES)-------------------------------------
Estas licencias serán concedidas por causas debidamente justificadas y por períodos
cortos, toda vez que el servidor público tenga derecho al uso de vacaciones
devengadas, percibiendo su haber mensual íntegramente durante el tiempo que dure
la licencia.------------------------------------------------------------------------
Estas licencias en el transcurso de una gestión, no podrán sobrepasar al 50% del

período anual de vacación que de acuerdo a escala le corresponda al servidor
público. Cada solicitud de licencia con cargo
a vacación tendrá un límite de tres días.------------------------------------------------------------
Toda licencia deberá tramitarse oportunamente y por escrito, utilizando los

formularios oficiales y siguiendo los procedimientos establecidos en la institución.-----
Artículo 43. (DERECHO A DESCANSO DE LA MUJER EMBARAZADA)------------------
La mujer embarazada, asegurada, tiene derecho a un descanso con el goce del

100% de su remuneración (sueldo o salario) 45 días antes hasta 45 días después del
alumbramiento o un tiempo mayor, si como consecuencia sobrevinieren casos de
enfermedad. Todo esto independientemente de los subsidios (Pre - natal, Lactancia y
Natalidad) que la ley le reconoce. (Art. 61 de la Ley General del Trabajo y D.L. 13214
de 24 de diciembre de 1.975).--------------------------------------------------------------------------
266 de 274
ANEXO D
JUSTIFICACION DE LA SELECCIÓN
DE LOS FACTORES DE COSTO EN COCOMO
El significado de los atributos es el siguiente, según su tipo:
De software
 RELY: garantía de funcionamiento requerida al software. Indica las posibles

consecuencias para el usuario en el caso que existan defectos en el producto.
Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la
posible pérdida de vidas humanas (extremadamente alto, software de alta
criticidad).
 DATA: tamaño de la base de datos en relación con el tamaño del programa.
El valor del modificador se define por la relación: D/K, donde D corresponde al
tamaño de la base de datos en bytes y K es el tamaño del programa en
cantidad de líneas de código.
 CPLX: representa la complejidad del producto.
De hardware
 TIME: limitaciones en el porcentaje del uso de la CPU.

 STOR: limitaciones en el porcentaje del uso de la memoria.
 VIRT: volatilidad de la máquina virtual.
 TURN: tiempo de respuesta requerido.
De personal
 ACAP: calificación de los analistas.

 AEXP: experiencia del personal en aplicaciones similares.
 PCAP: calificación de los programadores.
 VEXP: experiencia del personal en la máquina virtual.
267 de 274
 LEXP: experiencia en el lenguaje de programación a usar.
De proyecto
 MODP: uso de prácticas modernas de programación.

 TOOL: uso de herramientas de desarrollo de software.
 SCED: limitaciones en el cumplimiento de la planificación.
Justificación de valores:
 Fiabilidad Requerida del Software: En caso de que se registre algún dato

llegue a generar algún error (valoración alta).
 Tamaño de la Base de Datos: Por la cantidad de tablas y de datos que serán

almacenados en la base de datos (Valoración alta).
 Complejidad del Producto: Debido a las características del sistema se

considera medianamente compleja, ya que requiere realizarse la integración
de los subsistemas aplicando la arquitectura orientada a servicios a través de
los servicios web, además la integración del dispositivo biométrico con el
sistema (Valoración Medio).
 Restricciones del Tiempo de Ejecución: No existe ningún requerimiento

específico y relevante para el tiempo de ejecución del producto elaborado, por lo
cual se ha tomado el valor medio de la tabla. (Valoración Medio)
 Restricciones del Almacenamiento Principal: Existen restricciones al

respecto ya que se requiere de un servidor dedicado (Valoración Medio).
 Volatilidad de la Máquina Virtual: Esta característica no se aplica pero por ser

requerida según el modelo COCOMO se estima el valor más bajo. (Valoración
Bajo).
268 de 274
 Tiempo de respuesta del ordenador: Al tratarse de una aplicación web
requiere un tiempo de respuesta media, para que el usuario no tenga
inconvenientes (Valoración Media).
 Capacidad del Analista: El sistema para el proceso de evaluación no requiere

gran esfuerzo en la determinación de requerimientos y su modelado respectivo.
(Valoración Medio).
 Experiencia en Aplicaciones: Para realizar el sistema se requiere

conocimientos medios de integración de sistemas y manejo de dispositivos
biométricos (Valoración Media).
 Capacidad de los programadores: El autor del proyecto cuenta con poca

experiencia desarrollando un sistema completo para una institución (Valoración
Medio).
 Experiencia en Sistema Operativo utilizado: Se tiene el conocimiento

necesario para el desarrollo del sistema (Valoración Baja).
 Prácticas de programación modernas: Se cuenta con experiencia media en

el desarrollo de sistemas (Valoración Media)
 Utilización de Herramientas de Software: La experiencia en la utilización de

herramientas de software es necesario para la realización del sistema
integrado con dispositivo biométrico (Valoración Alta).
 Limitaciones de planificación del desarrollo del proyecto: Está sujeta al

cronograma de trabajo desarrollado (Valoración Media)
269 de 274
ANEXO E
CÁLCULOS PARA EL ANÁLISIS
BENEFICIO – COSTO
Tinta
Paquete de hojas
Costo de elaboración de informes y control de información de asistencia.
Para realizar los cálculos de los costos para los reportes se realizaron los siguientes
cálculos.
270 de 274
El máximo sueldo dentro de la institución es de 6000 Bs.- y el menor es de 2200 Bs.-
para obtener un sueldo medio se obtuvo la media de los dos sueldos como se mues-
tra a continuación.
Con el dato obtenido se calcularán el costo de los reportes.
 Verificar documentación:
 Registro biométrico.
 Información de asistencia.
 Información de faltas.
271 de 274
 Información de permisos.
 Solicitud de permiso para una fecha determinada.
272 de 274
ANEXO F
CUESTIONARIOS/ENTREVISTAS
Modelo de Cuestionario.
RESPODA A LAS SIGUIENTES PREGUNTAS.
1. ¿COMO SE REALIZA LA AMINISTRACION DEL KARDEX

ACTUALMENTE?
2. ¿SE OBTIENEN LOS REPORTES NECESARIOS DE LOS DIFERENTES

SUBSISTEMAS (ASISTENCIA, VACACIONES)?
3. ¿LOS SISTEMAS ACTUALES CUENTAN CON LA PARTICIPACION DE

LOS FUNCIONARIOS?
4. ¿CUAL ES EL PROCESO QUE SE SIGUE PARA REGISTRAR UN

USUARIO EN EL SISTEMA?
273 de 274
5. ¿QUE PROBLEMAS OCURREN AL PROCESAR LA INFORMACION DE
KARDEX?
6. ¿CUANTAS PERSONAS ESTAN INVOLUCRADAS EN EL MANEJO DE

LOS DIFERENTES SISTEMAS Y PROCESOS?
274 de 274

Sistema de Control de Personal Siskav

Cargado por

Copyright:

Formatos disponibles

Sistema de Control de Personal Siskav

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Control de Personal Siskav

Cargado por

Copyright:

Formatos disponibles

ESCUELA MILITAR DE INGENIERÍA

MCAL. ANTONIO JOSÉ DE SUCRE

SISTEMA DE CONTROL DE PERSONAL APLICANDO LA

YESMANI FERNANDEZ ARAMBULO

SISTEMA DE CONTROL DE PERSONAL APLICANDO LA

YESMANI FERNANDEZ ARAMBULO

Modalidad: Proyecto de Grado

TUTOR: LIC. MSC. DUNIA SOLIZ TORRICO.

A mi familia en especial a mis padres Delia Arámbulo y

A toda mi familia, por el apoyo incondicional, que me brindaron en el transcurso de mi vida.

Al personal administrativo, a los oficiales de la carrera de ingeniería de sistemas de la

Yesmani Fernández Arámbulo

El Sistema de Control de Personal aplicando la Arquitectura Orientada a Servicios e

Por lo tanto, se facilita la obtención de los reportes y además se obtienen reportes

En el primer capítulo perteneciente a generalidades se describen los antecedentes,

El segundo capítulo contiene toda la investigación teórica necesaria que se realizó

El tercer capítulo comprende toda la etapa de desarrollo en el cuál se emplea el

Para ello se pusieron en marcha los diferentes servicios (Kardex, Asistencia,

En el capítulo cuarto referente al análisis de viabilidad, se ha realizado un estudio de

En la viabilidad económica se determinó el costo de los elementos necesarios en

En el quinto capítulo se describen las conclusiones referidas a cada objetivo

En un mundo tan intercomunicado en el que vivimos, rodeado de miles de sistemas,

La arquitectura de SOA es una respuesta directa a las necesidades de las áreas de

En la actualidad las instituciones públicas y privadas atraviesan por una renovación

En muchos casos las instituciones gubernamentales carecen de medios que les

Existen una gran variedad en métodos y medios de gestión de asistencia y

En el ámbito de las tecnologías de la seguridad, uno de los problemas fundamentales

La biometría es una herramienta poderosa. Se rige por métodos automatizados de

La Ciudad de Cochabamba, fue fundada el 23 de Enero de 1826, durante la llegada

El Gobierno Municipal Autónomo de Cochabamba (G.M.A.C.) se divide en seis

Toda persona para ingresar a trabajar en la institución, debe cumplir

De resolverse la contratación en forma indefinida, se comunicará al postulante esta

Los procesos que se requieren evaluar para el proyecto se describen a continuación:

Del Kardex de personal:

La Unidad de recursos humanos, en su área de archivos, es la encargada de la

Al contar con mucho volumen de folders almacenados en los armarios, se crea el

Dentro de la unidad de Recursos Humanos, también se realiza el control de

Los encargados del control de asistencia cuentan con un sistema de escritorio

Por otra parte el sistema tiene limitaciones en su funcionamiento referidos al

El personal de la institución no puede abandonar sus labores durante la jornada de

Todo el personal tiene la obligación de registrar personalmente la hora de ingreso y

El Responsable de Registro de Asistencia, recibe el reporte de control de asistencia

Los directores de cada unidad, presentan a la Dirección Administrativa y de Recursos

El Rol de vacaciones Anual, deberá contemplar mínimamente la programación del

Los servidores públicos de la institución, tienen derecho de hacer uso de su vacación

La encargada de realizar las boletas de vacaciones del personal cuenta con un

1.3. PLANTEAMIENTO DEL PROBLEMA.

A continuación se mencionarán los siguientes puntos para poder determinar el

1.3.1. Identificación del problema.

A partir de las entrevistas y observaciones realizadas, se ha identificado el siguiente

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

 El almacenamiento del kardex del personal se realiza de forma manual en

1.3.1.2. Identificación de las causas.

Las causas identificadas en la situación problemática son:

 El almacenamiento del kardex del personal se realiza de forma manual en

1.3.2. Formulación del problema.

Los ineficientes procedimientos manuales, limitaciones técnicas y funcionamiento

1.3.3. Análisis causa efecto.

El análisis causa efecto es descrito a continuación: