Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Taller de Sistemas PDF
Taller de Sistemas PDF
PROYECTO DE GRADO
SISTEMA WEB PARA EL CONTROL Y ADMINISTRACIÓN DE
RECURSOS HUMANOS
CASO: EMPRESA DE LIMPIEZA INDUSTRIAL “TOTES LTDA”
PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA
MENCION: INGENIERIA DE SISTEMAS INFORMATICOS
LA PAZ – BOLIVIA
2014
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LICENCIA DE USO
(Jhonny)
Página | 2
AGRADECIMIENTOS
Ante todo a Dios por haberme dado una oportunidad más en mi vida para poder crecer como
persona y ser humano.
A mi Tutor Metodológico MSc. Jorge Teran por sus comentarios y observaciones que me
permitieron culminar con el presente proyecto.
A mi Asesor Lic. Marcelo Aruquipa por su asesoría, tiempo, dedicación y guía para el
desarrollo de este proyecto.
Página | 3
RESUMEN
Página | 4
INDICE GENERAL
1 CAPITULO I MARCO REFERENCIAL ....................................................................... 12
1.1 Introducción .......................................................................................................... 12
1.2 Antecedentes ....................................................................................................... 12
1.3 Planteamiento del Problema................................................................................. 15
1.4 Formulación del Problema .................................................................................... 16
1.5 Justificación .......................................................................................................... 16
1.6 Objetivos .............................................................................................................. 16
1.6.1 Objetivo Central ............................................................................................. 16
1.6.2 Objetivos Específicos .................................................................................... 17
1.7 Alcance ................................................................................................................ 17
1.7.1 Límites ........................................................................................................... 17
1.8 Metodología.......................................................................................................... 17
1.8.1 Tipo de Investigación ..................................................................................... 17
1.8.2 Metodología de Desarrollo ............................................................................. 17
1.9 Aporte................................................................................................................... 19
2 CAPITULO II MARCO TEORICO ................................................................................ 20
2.1 Introducción .......................................................................................................... 20
2.2 Marco Institucional................................................................................................ 20
2.2.1 Empresa de limpieza Industrial TOTE’s LTDA ............................................... 20
2.3 Administración de Recursos Humanos ................................................................. 23
2.3.1 Administración de personal............................................................................ 23
2.3.2 Objetivos y funciones de la Administración de personal ................................ 25
2.4 Ingeniería del Software ......................................................................................... 26
2.5 Modelos y Metodologías de Desarrollo ................................................................ 27
2.5.1 Metodología XP ............................................................................................. 27
2.6 Ingeniería Web ..................................................................................................... 32
2.6.1 Áreas ............................................................................................................. 32
2.6.2 Categorías ..................................................................................................... 33
2.6.3 Naturaleza multidisciplinaria .......................................................................... 34
2.7 Metodología de modelado Web – WEBML ........................................................... 34
2.7.1 El Modelo estructural ..................................................................................... 35
Página | 5
2.7.2 Modelo de derivación..................................................................................... 36
2.7.3 Modelo del hipertexto .................................................................................... 37
2.7.4 El Proceso de Diseño .................................................................................... 40
2.8 Herramientas para la Implementación .................................................................. 41
2.8.1 Java ............................................................................................................... 42
2.8.2 PostgreSQL ................................................................................................... 42
2.8.3 Framework Spring ......................................................................................... 43
2.9 Calidad de software .............................................................................................. 46
2.9.1 ISO 9126 ....................................................................................................... 47
2.10 Pruebas de Software ............................................................................................ 48
2.10.1 Objetivos ....................................................................................................... 49
2.10.2 Prueba unitaria .............................................................................................. 49
2.11 El modelo COCOMO ............................................................................................ 50
2.11.1 Modelo Básico ............................................................................................... 51
2.11.2 Modelo Intermedio ......................................................................................... 52
2.11.3 Modelo Detallado ........................................................................................... 53
2.11.4 Validación independiente del modelo COCOMO ........................................... 54
3 CAPITULO III MARCO APLICATIVO .......................................................................... 55
3.1 Introducción .......................................................................................................... 55
3.2 Análisis ................................................................................................................. 55
3.2.1 Análisis del Sistema actual ............................................................................ 55
3.2.2 Declaración de propósitos ............................................................................. 55
3.3 Valores de la Metodología XP .............................................................................. 55
3.3.1 Planificación incremental ............................................................................... 55
3.3.2 Pruebas ......................................................................................................... 56
3.3.3 Programación en parejas ............................................................................... 56
3.3.4 Refactorización .............................................................................................. 56
3.3.5 Diseño simple ................................................................................................ 56
3.3.6 Propiedad colectiva del código ...................................................................... 56
3.3.7 Integración continua ...................................................................................... 56
3.3.8 Cliente en el equipo ....................................................................................... 57
3.3.9 Pequeñas entregas........................................................................................ 57
3.3.10 Semanas de 40 horas.................................................................................... 57
Página | 6
3.3.11 Estándares de codificación ............................................................................ 57
3.4 Fase I: Exploración ............................................................................................... 57
3.4.1 Historias de Usuario ...................................................................................... 57
3.4.2 Detalle de las historias de usuario ................................................................. 61
3.5 Fase II: Planificación ............................................................................................ 62
3.5.1 Estimaciones de esfuerzo .............................................................................. 63
3.5.2 Planificación de iteraciones ........................................................................... 63
3.6 Fase III: Iteraciones .............................................................................................. 64
3.6.1 Primera iteración ........................................................................................... 64
3.6.2 Segunda Iteración ......................................................................................... 75
3.6.3 Tercera Iteración ........................................................................................... 78
3.6.4 Cuarta Iteración ............................................................................................. 81
3.7 Diagrama Jerárquico del sistema ......................................................................... 84
3.8 Modelado del sistema........................................................................................... 87
4 CAPÍTULO IV MÉTRICAS DE CALIDAD .................................................................... 93
4.1 Introducción .......................................................................................................... 93
4.2 Fiabilidad .............................................................................................................. 93
4.3 Funcionabilidad .................................................................................................... 95
4.3.1 Completitud de la implementación funcional .................................................. 95
4.3.2 Adecuación funcional..................................................................................... 95
4.4 Usabilidad ............................................................................................................ 96
4.5 Portabilidad .......................................................................................................... 98
4.6 Mantenimiento ...................................................................................................... 99
4.7 Análisis de Costos ................................................................................................ 99
5 CAPÍTULO V CONCLUSIONES Y RECOMENDACIONES ....................................... 102
5.1 Conclusiones ...................................................................................................... 102
5.2 Recomendaciones .............................................................................................. 102
6 BIBLIOGRAFÍA ......................................................................................................... 104
Página | 7
INDICE DE FIGURAS
Figura 1.1 Organigrama de la Empresa (Mendez, 2013) ...................................................... 13
Figura 2.1: Oficina central TOTE's LTDA (TOTE's, 2011) ..................................................... 22
Figura 2.2: Ramas de la Administración General (Marconi, 2012) ........................................ 24
Figura 2.3: Definición de Administración de Personal (Marconi, 2012) ................................. 24
Figura 2.4: Funciones de la Administración de Personal (Marconi, 2012) ............................. 26
Figura 2.5: Kent Beck (Fernández, 2002) ............................................................................. 27
Figura 2.6: El coste del cambio (Fernández, 2002) ............................................................... 28
Figura 2.7: Iteraciones y planes de iteración (Fernández, 2002) ........................................... 29
Figura 2.8: Modelo de tarjeta CRC (Anaya) .......................................................................... 30
Figura 2.9 Ejemplo de modelo estructural (webml.org) ......................................................... 36
Figura 2.10 Ejemplo de modelo de derivación (Ceballos, Arboleda, & Casallas, 2008)......... 36
Figura 2.11 Ejemplo de un modelo de hipertexto (webml.org) .............................................. 38
Figura 2.12 Ejemplo de Modelo de Presentación (tecnologimerlin, 2007) ............................. 40
Figura 2.13 Proceso de diseño (webml.org) .......................................................................... 41
Figura 2.14 Componentes de un sistema PostgreSQL (Martinez, 2010) ............................... 43
Figura 2.15 Spring Framework Runtime (SpringFramework) ................................................ 44
Figura 2.16 Gestión de Calidad (Noriega Quintana, 2007) .................................................... 47
Figura 3.1: Cronograma de desarrollo por iteraciones .......................................................... 64
Figura 3.2: Estructura de datos para registrar la información del usuario y funcionario ......... 64
Figura 3.3: Pantalla de búsqueda de funcionarios para posterior registro como funcionario . 65
Figura 3.4: Listado de funcionarios encontrados ................................................................... 65
Figura 3.5: Mensaje de que no se puede registrar como usuario porque no se trata de un
funcionario activo .................................................................................................................. 66
Figura 3.6: Pantalla de registro de usuario en caso de que el funcionario este en estado
activo .................................................................................................................................... 66
Figura 3.7: Estructura de datos para registrar la información del funcionario ........................ 67
Figura 3.8: Pantalla de inicio para verificar la existencia de un funcionario ........................... 68
Figura 3.9: Pantalla para el registro de información del funcionario ...................................... 68
Figura 3.10: Pantalla de anuncio de que el funcionario tiene datos almacenados................. 69
Figura 3.11: Pantalla para lanzar el módulo de re afiliación del funcionario .......................... 69
Figura 3.12: Modulo para la re afiliación del funcionario ....................................................... 70
Figura 3.13: Estructura de datos para registrar la información de un contrato ...................... 71
Figura 3.14: Modulo para el registro de un nuevo contrato ................................................... 71
Figura 3.15: Modulo para el llenado de datos de un nuevo contrato ..................................... 72
Figura 3.16: Modulo para el registro de un nuevo contrato pantalla de contrato registrado ... 72
Figura 3.17: Pantalla de búsqueda de un contrato cerrado ................................................... 73
Figura 3.18: Pantalla de listados de contratos cerrados ........................................................ 73
Figura 3.19: Pantalla de interfaz de apertura de un contrato ................................................. 74
Figura 3.20: Pantalla de aviso de que el contrato fue abierto correctamente ........................ 74
Figura 3.21: Diseño de la tabla para registro de documentos del funcionario ....................... 75
Figura 3.22: Pantalla de listado de documentos del funcionario ............................................ 76
Página | 8
Figura 3.23: pantalla para subir y almacenar un documento en el sistema ........................... 76
Figura 3.24: Pantalla de descarga de documentos digitalizados ........................................... 77
Figura 3.25: Diseño de la tabla para el control de las asistencias de un funcionario ............. 78
Figura 3.26: Pantalla delo listado de asistencias registradas de los funcionarios de un
contrato................................................................................................................................. 78
Figura 3.27: Diseño del formulario para el registro de asistencias de los funcionarios que
trabajaron en un respectivo contrato ..................................................................................... 79
Figura 3.28: Pantalla de inicio mostrando el estado del registro de las asistencias de los
contratos supervisados ......................................................................................................... 80
Figura 3.29: Modulo del llenado de datos de las asistencias para un contrato en particular.. 80
Figura 3.30: Estado del listado de asistencias después del registro de datos ....................... 81
Figura 3.31: Diseño preliminar del reporte de la planilla por contratos .................................. 82
Figura 3.32: Modulo para generar planillas por contratos ..................................................... 82
Figura 3.33: Reporte de la planilla del mes ........................................................................... 83
Figura 3.34: Diagrama jerárquico del sistema ....................................................................... 84
Figura 3.35: Diagrama de clases del modelo ........................................................................ 85
Figura 3.36 Modelo estructural ............................................................................................. 87
Figura 3.37 Modelo de derivación (Registrar Usuario) .......................................................... 88
Figura 3.38 Modelo de derivación (Registro de un funcionario) ............................................ 88
Figura 3.39 Modelo de derivación (registrar contrato) ........................................................... 89
Figura 3.40 Modelo de derivación (Registro de documentación de un funcionario) ............... 89
Figura 3.41 Modelo de derivación (Registro de asistencias) ................................................. 90
Figura 3.42 Modelo de derivación (Generación de planillas) ................................................. 90
Figura 3.43 Modelo de hipertexto (Administrador) ................................................................ 91
Figura 3.44 Modelo de hipertexto (Jefe de Recursos Humanos) ........................................... 91
Figura 3.45 Modelo de hipertexto (Supervisor) ..................................................................... 92
Figura 3.46 Modelo de Presentación .................................................................................... 92
Página | 9
INDICE DE TABLAS
Tabla 2.1: Modelo propuesto para una historia de usuario (Anaya) ...................................... 28
Tabla 2.2 Coeficientes (Dolado) ............................................................................................ 51
Tabla 3.1 Historia de Usuario - registro de un nuevo Usuario ............................................... 58
Tabla 3.2 Diseñar la estructura de datos para registrar la información del usuario y
funcionario ............................................................................................................................ 58
Tabla 3.3 Tarea - Registro de datos del usuario ................................................................... 59
Tabla 3.4 Tarea - Habilitación de solo funcionarios activos para ser asignados como usuarios
............................................................................................................................................. 59
Tabla 3.5 Historia de usuario - Registro de funcionarios ....................................................... 60
Tabla 3.6 Diseño de la base de datos para la información del funcionario ............................ 60
Tabla 3.7 Tarea - Modulo de registro de información de un funcionario ................................ 61
Tabla 3.8 Tarea - Módulo de re afiliación de un ex funcionario ............................................. 61
Tabla 3.9 Administración de usuarios ................................................................................... 63
Tabla 3.10 Administración de funcionarios............................................................................ 63
Tabla 3.11 Administración y control de asistencias ............................................................... 63
Tabla 3.12 Generación de reportes de planillas .................................................................... 63
Tabla 3.13 Cronograma en detalle de las historias de usuario .............................................. 63
Tabla 3.14 Acceso de los usuarios a los diferentes módulos del sistema ............................. 85
Tabla 4.1 Fiabilidad .............................................................................................................. 93
Tabla 4.2 Análisis de la fiabilidad .......................................................................................... 94
Tabla 4.3 Fiabilidad a la finalización del proyecto ................................................................. 94
Tabla 4.4 Fiabilidad a la finalización del proyecto ................................................................. 94
Tabla 4.5 Análisis de la funcionabilidad ................................................................................ 96
Tabla 4.6 Mejora de la funcionabilidad a la finalización del proyecto .................................... 96
Tabla 4.7 Análisis de los datos de la usabilidad .................................................................... 97
Tabla 4.8 Mejora en la usabilidad del sistema ...................................................................... 98
Tabla 4.9 Análisis de los datos de portabilidad ..................................................................... 98
Tabla 4.10 Análisis de los datos de portabilidad a la finalización del proyecto ...................... 99
Tabla 4.11 Resumen de Métricas de Calidad ....................................................................... 99
Tabla 4.12 Conteo estimado del Total de líneas de código durante el desarrollo ................ 100
Tabla 4.13 Costo del proyecto ............................................................................................ 101
Tabla 6.1 Historia de usuario - Registro de contratos.......................................................... 107
Tabla 6.2 Tarea - Diseño de la base de datos para la información de un contrato .............. 107
Tabla 6.3 Tarea - Modulo de registro de información de un contrato .................................. 107
Tabla 6.4 Tarea - Modulo de re apertura de un contrato cerrado ........................................ 108
Tabla 6.5 Historia de usuario - Verificar el estado de la documentación de un funcionario . 108
Tabla 6.6 Tarea - Diseño de la base de datos para la información de la documentación de un
funcionario .......................................................................................................................... 109
Tabla 6.7 Tarea - Modulo de registro de documentos del funcionario ................................. 109
Tabla 6.8 Tarea - Modulo de descarga de documentos digitalizados .................................. 110
Tabla 6.9 Historia de usuario - Verificar el estado de las asistencias de los funcionarios .... 110
Página | 10
Tabla 6.10 Tarea - Diseño de la base de datos para la información de las asistencias de un
funcionario .......................................................................................................................... 111
Tabla 6.11 Tarea - Modulo de verificación de asistencias de los funcionarios por contratos y
general ............................................................................................................................... 111
Tabla 6.12 Historia de usuario - Registrar asistencias de los funcionarios .......................... 111
Tabla 6.13 Tarea - Diseño del formulario para el registro de las asistencias ....................... 112
Tabla 6.14 Modulo de verificación de asistencias de los funcionarios por contrato y general
........................................................................................................................................... 112
Tabla 6.15 Historia de usuario - Generar reportes de planilla de sueldos por contrato........ 113
Tabla 6.16 Tarea - Diseño del reporte de la planilla por contratos ...................................... 113
Tabla 6.17 Tarea - Modulo de generación de reportes de planilla de sueldos ..................... 114
Página | 11
1 CAPITULO I
MARCO REFERENCIAL
1.1 Introducción
Las Tecnologías de la Información están transformando las actividades económicas y
cotidianas como uno de los fenómenos sociológicos más importantes del siglo.
Indiscutiblemente, las computadoras han invadido ya todos y cada uno de los campos de la
actividad humana: ciencia, tecnología, arte, educación, recreación, administración, economía
y de acuerdo a la tendencia actual, nuestra civilización y las venideras dependerán cada vez
más de estos "cerebros" electrónicos.
Se ha venido acelerando la velocidad de cambio del medio de casi todas las organizaciones,
de allí que éstas necesiten ahora más información como soporte a la toma de decisiones. Es
por eso que, el desarrollo de sistemas para el manejo de información viene jugando un papel
importante y cada vez más preponderante para poder competir y subsistir en el medio.
Una empresa de limpieza industrial que presta servicios de limpieza con personal calificado
no se queda al margen, emplea las hojas electrónicas de tipo EXCEL generadas por un
programa de computador, en diferentes actividades como es el de administrar la información
del personal operativo (personal de planta u obreros) y administrativo, control de asistencia,
asignación de turnos de trabajo, permisos con licencia, planillas de pago, etc.
1.2 Antecedentes
La empresa de limpieza industrial “TOTES LTDA” presta sus servicios a instituciones
públicas y privadas, Totes La Paz empezó sus operaciones el 10 de abril de 1986, La
primera sucursal de Totes se inauguró el 30 abril de 1993 en la ciudad de Cochabamba.
Viendo el éxito de esta, el 12 abril de 1997 se abren las puertas de Totes Santa Cruz. Años
después se abre Totes Sucre (1ro de Octubre, 2002) y Totes Tarija (8 de agosto, 2003)
atendiendo también a Potosí y Oruro.
Página | 12
“Ser la empresa líder del mercado de limpieza nacional, contando con reconocimiento
internacional, donde cada cliente encuentre las soluciones que necesita y su personal
encuentre un lugar donde crecer, todo esto en un marco de respeto al medio ambiente.”
(TOTE's, 2011)
Es una institución que brinda sus servicios de limpieza industrial con personal calificado a
nivel nacional, alguno de estos servicios que presta son:
Lavado de alfombras.
Lavado y pulido de pisos fríos.
Limpieza de vidrios interiores y exteriores.
Desengrasado de cocinas.
Lavado de tapices y colchones.
Limpieza en seco de alfombras.
Desinfectado y sanitizado de baños.
Lavado profundo de interior de automóviles.
Ozonizado de ambientes.
Extracción de agua en caso de inundaciones.
Mantenimiento general y desempolvado de oficinas.
Servicio de jardinería, cafetería y mensajería.
Fumigado de ambientes.
El jefe de recursos humanos depende directamente del gerente regional, cada regional
cuenta con supervisores de contratos que dependen del jefe de recursos humanos, a la vez
cada supervisor controla a los operarios de los distintos subcontratos, en cada subcontrato
hay un jefe de grupo y un número de operarios por contrato.
Gerente Nacional
Gerente de Gerente
Personal Administrativo
Servicios a
Contratos
Domicilio
Operario de
Supervisor
Limpieza
Página | 13
La empresa de limpieza industrial “TOTES LTDA” está compuesta por varias áreas, una de
ellas es la de recursos humanos en la que se realizan actividades como ser:
Reclutamiento de personal.
Capacitación de personal en el área de limpieza industrial.
Administración de la documentación del personal.
Asignación del personal a determinadas áreas de trabajo.
Supervisión y control de asistencia del personal
Elaboración de planillas de pago.
Proyectos Similares
(Llanque, 2009)
(Delgado, 2008)
El presente proyecto desarrollado con el tema “Sistema de
Administración de Personal Instituto Nacional de Reforma Agraria”, que
da respuesta a la carencia de información oportuna y precisa acerca
del control, seguimiento de documentación y evaluación del personal y
los diferentes tramites que se generan y realizan al interior de la unidad
a nivel nacional y que son que son depositados y custodiados por la
unidad de archivos.
Para el proceso de desarrollo del sistema se utilizó la metodología
OHDM, el lenguaje de modelado UML, en cuanto a la implementación
se empleó el motor de base de datos MySQL.
(Nina)
Página | 14
El presente proyecto fue desarrollado en el Hospital Agramont. La
Unidad de Talento Humano no cuenta con un sistema automatizado y
estos procesos se los realiza de forma manual ocasionando volúmenes
de papelería con información muy importante a la intemperie.
Para el desarrollo del sistema se utilizó la metodología RUP y se apoya
en UML, la herramienta de desarrollo fue SQL Server 2000, Cristal
Reports 2003 y Visual Basic .NET 2005
(Mamani, 2011)
La función de los Recursos Humanos ha evolucionado desde una
concepción eminentemente administrativa, en la que lo fundamental
era la confección de nómina, establecimiento y mantenimiento de un
sistema de administración de RRHH.
Durante la etapa de análisis se realiza y se aplica las fase de la
metodología XP aplicando el diseño con UML así también para la parte
navegacional se usa OOHDM. Por otra parte la codificación se realizó
con el lenguaje PHP, Servidor Apache y gestor de base de datos
MySQL.
(Chávez, 2007)
En la institución es fundamental administrar los datos de los
funcionarios de acuerdo a los requerimientos del usuario. Por esta
razón se realiza el Sistema de Administración de Recursos Humanos
para el CEMSE, basado en computador con el propósito de reducir el
tiempo de procesamiento de los registros personales y la obtención de
información confiable, segura e integra para un mejor servicio a la
institución y al personal.
Se hace uso de Relationship Management Methology – RMM basado
en enfoque estructurado y navegacional de un documento de
hipertexto. En la implementación se hace uso del lenguaje PHP, para el
gestor de base de datos se hace uso de MySQL.
Página | 15
antes no trabajo o ver si no tenía antecedentes de mala conducta en contra de la
empresa, descuentos injustificados, etc.
El proceso de reclutamiento de personal es manual, recolectando la
documentación en forma no organizada lo que conlleva al retraso en la asignación
de áreas de trabajo a los nuevos operarios.
Frecuentemente hay llamadas de atención contra la empresa por la seguridad de
los ambientes de trabajo en los subcontratos, esto se debe a que los certificados
de antecedentes del personal no son actualizados periódicamente. Y no se sabe
cuándo deben actualizar sus datos y quienes aún no completaron la
documentación de garantías personales.
El control de asistencias solo se realizan de acuerdo a una pre-planilla que realiza
el supervisor de contrato, no pudiendo constatarse el cumplimiento de los horarios
de cada operario.
La emisión de memorándums es manual y se entregan con un retraso de varios
días lo que implica una informalidad para los operarios y los supervisores.
1.5 Justificación
La ejecución del proyecto optimizara el control de personal en forma automática, logrando
con esto reducir la intervención de recurso humano para realizar la elaboración de planillas
de la empresa para la cual se realiza el proyecto, cuenta con los equipos con las
características mínimas necesarias para la implementación del sistema. El software a utilizar
en el desarrollo del proyecto no necesita licencia, por lo que es más económico al momento
de la implementación. El sistema será desarrollado en un lenguaje de programación
orientado a objetos basados en Web, con un gestor de base de datos fiable y estarán sobre
un servidor con un sistema operativo Linux, los mismos que tienen la característica de ser
software libre.
1.6 Objetivos
Página | 16
1.6.2 Objetivos Específicos
Mantener la información actualizada de la documentación del personal como
ser certificados de antecedentes, documentos de contratación, documentos
del garante, etc.
Realizar el control de los permisos y faltas del personal operativo y
administrativo.
Automatizar la emisión de reportes, informes e historial de asistencias del
personal operativo y administrativo, informes sobre el estado de los contratos
y el personal existente y faltante en cada una de las instituciones a las que se
brinda el servicio de limpieza industrial.
Diseñar e Implementar una base de datos para el manejo de la información
referente a los recursos humanos, implementar procedimientos almacenados
para el mejor manejo de los datos en el gestor de base de datos.
1.7 Alcance
Los alcances del Sistema Web para el Control y Administración de Recursos Humanos
serán:
1.7.1 Límites
El sistema Web tendrá las siguientes limitaciones:
1.8 Metodología.
Página | 17
1.8.2.1 Para la Planificación
En el ciclo de vida de eXtreme Programming la primera fase es la exploración, fase en la que
se planean las historias de usuario, al mismo tiempo se familiariza con las herramientas,
tecnología y prácticas que se utilizaran en el presente proyecto. Se probara la tecnología y
se explorara las posibilidades de la arquitectura del sistema construyendo un prototipo.
Para el caso de programación en parejas solo se contara con un programador que estará
totalmente involucrado en el proyecto.
1.8.2.4 Pruebas:
Se plantea realizar pruebas para comprobar el funcionamiento de los códigos que se vayan a
implementar en el sistema.
Se crearan las aplicaciones que realizarán los test con un entorno de desarrollo
específico para cada prueba.
Se someterá a pruebas las distintas clases del sistema omitiendo los métodos más
triviales.
Se crearan las pruebas que pasarán los códigos antes de implementarlos
Página | 18
o Diagramas UML de clases que pueden representar la misma información que
un diagrama de Entidad-Relación (por lo puede usarse de manera
equivalente), e incluso información adicional sobre el modelo de datos.
Modelo de Hipertexto: Un modelo por cada hipertexto, cada hipertexto describe una
vista del sitio.
Modelo de composición: Representa las páginas de un hipertexto y cada página
que elementos de contenido tiene.
Modelo de navegación: Representa los enlaces entre las diferentes páginas y sus
elementos de contenido
La orientación a objetos ha tomado por asalto y en forma legítima al mundo del software.
Como medio para la generación de programas, tiene varias ventajas. Fomenta una
metodología basada en componentes para el desarrollo de software, de manera que primero
se genere un sistema mediante un conjunto de objetos, luego se podrá ampliar el sistema
agregándole funcionalidad a los componentes que ya habría generado o agregándole
nuevos componentes, y finalmente podrá volver a utilizar los objetos que generó para el
sistema cuando cree uno nuevo, con lo cual reducirá sustancialmente el tiempo de desarrollo
de un sistema.
La orientación a objetos se refiere a algo más que tan sólo atributos y acciones; también
considera otros aspectos. Dichos aspectos se conocen con abstracción, herencia,
polimorfismo y encapsulamiento o encapsulación. Otros aspectos importantes se la
orientación a objetos son: él envió de mensajes, las asociaciones y la agregación.
1.9 Aporte
El Sistema web para el Control y Administración de Recursos Humanos muestra cómo se
puede realizar el control de las asistencias del personal dispersado en diferentes contratos
mediante relojes biométricos en contratos grandes y bajo reportes de asistencia de los
supervisores en contratos pequeños que al combinarlos permiten la reducción del tiempo de
acceso de la información y con esto se posibilite la ejecución de otras tareas en el
departamento de Recursos Humanos.
Página | 19
2 CAPITULO II
MARCO TEORICO
2.1 Introducción
Realizar un Sistema Web para el Control y Administración de Recursos Humanos requiere
del conocimiento de metodologías de desarrollo que utilicen modelos y estructuras formales
de diseño e implementación de software, que ayuden a la programación de tareas antes de
la construcción del sistema, obtener los requerimientos del usuario y organizar cada una de
las etapas de entrega de prototipos y pruebas del sistema, esto con el fin de mantener un
cuidadoso manejo de la información de los funcionarios y cumplir con las expectativas del
usuario final que hará uso de los módulos del sistema más concretamente los módulos de
administración y control de recursos humanos.
En este capítulo se describirá los conceptos referentes a la metodología que se usara como
línea referencial en el proceso de desarrollo de software, por otro lado también se detallará
los conceptos básicos del patrón modelo vista controlador, descripción del mapeo
objeto/relacional, es decir como a partir de un modelo de datos orientado a objetos se
consigue su almacenamiento en una base de datos relacional; para ello se hará el uso del
framework spring y sus propios métodos para las consultas a la base de datos JDBC, que
precisamente nos permitirá esta conversión y principalmente el desarrollo de la aplicación
netamente orientado a objetos sin la necesidad de preocuparse por la conversión manual
para el almacenamiento en la base de datos relacional.
Totes La Paz empezó sus operaciones el 10 de abril de 1986 con la idea visionaria del señor
Carlos España y su esposa Isabel Ayala de España. Empezaron las operaciones de Totes
desde el pequeño departamento donde vivían junto a algunos amigos y familiares que los
apoyaron desde el principio.
(TOTE's, 2011)
En esta época el Sr. España realizaba la limpieza, siguiendo el entrenamiento que
recibió cuando vivía en Estados Unidos, mientras que la Sra. España atendía
Página | 20
llamadas y manejaba la primera combi Volkswagen que compraron de segunda
mano. Poco a poco fueron creciendo y lograron alquilar la primera oficina de Totes en
la zona de Sopocachi frente a la Plaza del Cóndor. Cuentan que durante estos años
era muy común ver alfombras colgadas de las alas de la estatua del cóndor por la
falta de espacio en la oficina. Mientras los trabajos iban aumentando también crecía
la familia Totes.
Misión
Visión
“Ser la empresa líder del mercado de limpieza nacional, contando con reconocimiento
internacional, donde cada cliente encuentre las soluciones que necesita y nuestro personal
encuentre un lugar donde crecer, todo esto en un marco de respeto al medio ambiente”.
(TOTE's, 2011)
Página | 21
Figura 2.1: Oficina central TOTE's LTDA (TOTE's, 2011)
(TOTE's, 2011)
LAVADO DE ALFOMBRAS: Limpieza a presión con agua y extracción inmediata
que lava las fibras desde su base, recomendado por la mayoría de fabricantes de
alfombras.
Página | 22
acumulan a diario en todas las superficies del domicilio y oficina, dejando todo
brillando de limpio.
(Mendez, 2013)
Gerente General
Gerente Regional
Jefe de Contabilidad
Jefe de Almacenes
Jefe de Recursos Humanos
Secretarias y Administrativos
Choferes
Supervisores
Encargados de Contrato
Operarios de Limpieza
Personal de Planta
Página | 23
Figura 2.2: Ramas de la Administración General (Marconi, 2012)
Página | 24
Es la disciplina que se encarga de organizar a los trabajadores y a las
personas que laboran en una empresa para alcanzar los objetivos de
ambas partes.
2.3.2.1 Objetivos
(Marconi, 2012) Afirma
La Administración de Personal se reconoce como un área interdisciplinaria, y tiene
como objeto de estudio y de acción la administración de las personas vinculadas
directa o indirectamente a una empresa o conjunto de empresas, a partir de la
búsqueda de una coherencia cultural mínima en su dimensión laboral. El propósito
fundamental de la Administración de recursos humanos es mejorar las contribuciones
productivas del personal a la organización. (p. 3)
2.3.2.2 Importancia
Toda disciplina reviste importancia igual que la Administración de Personal, la que adquiere
su importancia al evitar o solucionar situaciones como:
Demandas laborales.
Por lo anterior, esta disciplina debe de llevar a cabo acciones para proporcionar y
mantener una fuerza de trabajo adecuada, es decir, con las características y en la
cantidad que la organización necesita para lograr su propósito. (p. 3)
Página | 25
Figura 2.4: Funciones de la Administración de Personal (Marconi, 2012)
2.3.2.3 Funciones
(Marconi, 2012) Afirma
Página | 26
2. Todos los aspectos de producción de software. La ingeniería del software no
sólo comprende los procesos técnicos del desarrollo de software, sino también
con actividades tales como la gestión de proyectos de software y el desarrollo de
herramientas, métodos y teorías de apoyo a la producción de software.
2.5.1 Metodología XP
La Programación Extrema es una metodología ágil de desarrollo de software que se basa
en la simplicidad, la comunicación y la realimentación o reutilización del código desarrollado.
XP surgió como respuesta y posible solución a los problemas derivados del cambio en los
requerimientos se plantea como una metodología a emplear en proyectos de riesgo aumenta
la productividad.
Página | 27
Figura 2.6: El coste del cambio (Fernández, 2002)
Historias de usuario
Descripción:
Observaciones:
Página | 28
Iteraciones y planes de iteración
La velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla
el proyecto. Usando la velocidad del proyecto se controla todas las tareas que se puedan
desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida
cada 3 ó 4 iteraciones y si se nota que no es adecuada hay que negociar con el cliente un
nuevo (Plan de Entregas).”
Programación en pareja
2ªfase: Diseño
(Anaya)
Diseños simples. La metodología X.P sugiere que hay que conseguir diseños
simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible
para conseguir un diseño fácilmente entendible e implementable que a la larga
costará menos tiempo y esfuerzo desarrollar.
Página | 29
nuevo estos códigos para procurar optimizar su funcionamiento. Es muy común
rehusar códigos ya creados que contienen funcionalidades que no serán usadas y
diseños obsoletos. Esto es un error porque puede generar código completamente
inestable y muy mal diseñado; por este motivo, es necesario refactorizar cuando
se va a utilizar código ya creado.
3ª Fase: Codificación.
Como ya se dijo, el cliente es una parte más del equipo de desarrollo; su presencia es
indispensable en las distintas fases de X.P. A la hora de codificar una historia de usuario su
presencia es aún más necesaria. Los clientes son los que crean las historias de usuario y
negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada historia
de usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá que
estar presente cuando se realicen los test que verifiquen que la historia implementada
cumple la funcionalidad especificada.
Crear test que prueben el funcionamiento de los distintos códigos implementados permite
ayudar a desarrollar dicho código. Crear estos test antes ayuda a saber qué es exactamente
lo que tiene que hacer el código a implementar y saber que una vez implementado pasará
dichos test sin problemas ya que dicho código ha sido diseñado para ese fin. Se puede
dividir la funcionalidad que debe cumplir una tarea a programar en pequeñas unidades, de
Página | 30
esta forma se crearán primero los test para cada unidad y a continuación se desarrollará
dicha unidad, así poco a poco se consigue un desarrollo que cumpla todos los requisitos
especificados. X.P opta por la programación en pareja ya que permite un código más
eficiente y con una gran calidad.
(Anaya)
X.P sugiere un modelo de trabajo usando repositorios de código dónde las parejas de
programadores publican cada pocas horas sus códigos implementados y corregidos
junto a los test que deben pasar. De esta forma el resto de programadores que
necesiten códigos ajenos trabajarán siempre con las últimas versiones. Para
mantener un código consistente, publicar un código en un repositorio es una acción
exclusiva para cada pareja de programadores.
La optimización del código siempre se debe dejar para el final. Hay que hacer que
funcione y que sea correcto, más tarde se puede optimizar.
X.P afirma que la mayoría de los proyectos que necesiten más tiempo extra que el
planificado para ser finalizados no podrán ser terminados a tiempo se haga lo que se
haga, aunque se añadan más desarrolladores y se incrementen los recursos. La
solución que plantea X.P es realizar un nuevo "Release plan" para concretar los
nuevos tiempos de publicación y de velocidad del proyecto.
4ª Fase: Pruebas.
(Anaya)
El uso de los test en X.P es el siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno de
desarrollo específico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los métodos
más triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en el
apartado anterior se explicó la importancia de crear antes los test que el código.
Página | 31
Un punto importante es crear pruebas que no tengan ninguna dependencia del código que
en un futuro probará. Hay que crear las pruebas absteniéndose de saber cómo será el futuro
código, de esta forma se asegura la independencia de la prueba respecto al código que
evalúa.
(Anaya)
“El uso de los test es adecuado para observar la refactorización. Los test permiten
verificar que un cambio en la estructura de un código no tiene por qué cambiar su
funcionamiento. Test de aceptación. Los test mencionados anteriormente sirven para
evaluar las distintas tareas en las que ha sido dividida una historia de usuario. Para
asegurar el funcionamiento final de una determinada historia de usuario se deben crear
(Test de aceptación); estos test son creados y usados por los clientes para comprobar
que las distintas historias de usuario cumplen su cometido. Al ser las distintas
funcionalidades de nuestra aplicación no demasiado extensas, no se harán test que
analicen partes de las mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa especificado en la descripción
de requisitos.”
La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web y como
está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la
información en las diferentes áreas en que se presenta, ha hecho que las personas tiendan a
realizar todas sus actividades por esta vía.
2.6.1 Áreas
El desarrollo de aplicaciones Web posee determinadas características que lo hacen diferente
del desarrollo de aplicaciones o software tradicional y sistemas de información. La ingeniería
Web es multidisciplinaria y aglutina contribuciones de diferentes áreas como ser: la
arquitectura de la información, ingeniería de hipermedia/hipertexto, ingeniería de requisitos,
diseño de interfaz del usuario, usabilidad, diseño gráfico y de presentación, diseño y análisis
de sistemas, ingeniería de software, ingeniería de datos, indexado y recuperación de
información, testeo, modelado y simulación, despliegue de aplicaciones, operación de
sistemas y gestión de proyectos.
Página | 32
utiliza principios de ingeniería de software, incluye nuevos enfoques, metodologías,
herramientas, técnicas, guías y patrones para cubrir los requisitos únicos de las aplicaciones
web. Sin embargo el término de ingeniería web ha sido un término muy controvertido
especialmente para profesionales en disciplinas tales como la ingeniería del software ya que
no la consideran como un campo dentro de la ingeniería.
2.6.2 Categorías
(Wikipedia-IngenieríaWeb, 2014) Afirma
Los sitios web pueden ser categorizados de la siguiente forma:
Página | 33
usuarios la interacción por medio de cuestionarios, comentario y
sugerencias.
Sitio con acceso de datos dinámicos aquí, además de las características
antes mencionadas, cuenta con bases de datos en las cuales el usuario
puede realizar consultas y búsquedas.
Sitio creado dinámicamente en este sitio los requerimientos son parecidos
pero deben suplir con las necesidades de cada usuario; creando sitios
dinámicos que sean compatibles con el entorno de navegación de cada
usuario.
Aplicación de software basada en la Web este sitio puede tener todas las
características antes mencionadas, pero logrando un parecido con una
implementación cliente/servidor comúnmente conocido que a un sitio web
estático.
(webml.org) Afirma
WebML proporciona es un entorno gráfico formal con especificaciones incluidas en un
proceso del planificación completo que se ayuda con elementos visuales. Los
objetivos principales del proceso del diseño WebML son:
a) Expresar la estructura de una aplicación de Web con una descripción de alto
nivel orientado a la evolución, y mantenimiento;
b) Proporcionar múltiples vistas de un mismo modulo;
c) Separar la información de la que está en páginas de composición, navegación
y presentación que pueden definirse y pueden reestructurarse
independientemente;
d) Guardar la meta-información durante el proceso de planificación dentro de una
base de datos para que esta pueda usarse durante la vida de la aplicación de
páginas Web para que estas de generen dinámicamente;
e) Permitir a los usuarios la especificación de políticas de personalización de una
a una de las aplicaciones;
Página | 34
f) Habilitar la especificación de la funcionabilidad del manejo de los datos para
que este actualizada y actuar recíprocamente con los servicios externos.
Traducción mía
WebML provides graphical, yet formal, specifications, embodied in a complete
design process, which can be assisted by visual design tools. The main objectives
of the WebML design process are:
a) expressing the structure of a Web application with a high-level description,
which can be used for querying, evolution, and maintenance;
b) providing multiple views of the same content;
c) separating the information content from its composition into pages,
navigation, and presentation, which can be defined and evolved
independently;
d) storing the meta-information collected during the design process within a
repository, which can be used during the lifetime of the application for
dynamically generating Web pages;
e) modelling users and communities explicitly in the repository, to permit the
specification of personalization policies and one-to-one applications;
f) Enabling the specification of data manipulation operations for updating the
site content or interacting with arbitrary external services.
Traducción mía
The WebML data model is a suitable adaptation of conceptual models for data design,
as already in use in other disciplines, such as database design, software engineering,
and knowledge representation. It is compatible with the Entity-Relationship data
model, used in conceptual database design, and with UML class diagrams, used in
object-oriented modeling. The fundamental elements of data models are entities,
defined as containers of data elements, and relationships, defined as semantic
connections between entities. Entities have named properties, called attributes, with
Página | 35
an associated type. Entities can be organized in generalization hierarchies and
relationships can be restricted by means of cardinality constraints. Instances of
entities are considered individually addressable by means of a unique identifier
(OID). WebML OIDs are abstract concepts, which can be implemented in alternative
ways in the underlying storage manager, e.g., primary keys in a relational data store
or XML ID attributes in a XML data source.
In other words it is similar to VIEWS in databases modelling. Like VIEW in Oracle or MySQL.
For each page there is One abstract Table of datas. But it is merged from other tables.
Traducción mía.
Figura 2.10 Ejemplo de modelo de derivación (Ceballos, Arboleda, & Casallas, 2008)
Página | 36
2.7.3 Modelo del hipertexto
El modelo más importante de la metodología de WebML, modela la navegación de usuario
en la red.
(webml.org) Afirma
La composición describe qué páginas componen el hipertexto, y qué unidades
satisfechas constituyen una página. Las páginas del sitio de Web realmente son los
recipientes de información entregados al lector.
Las unidades son los elementos en la información descrita en el modelo de datos.
Siete tipos de unidades son los componentes de páginas predefinidos en WebML: los
datos, los multi-datos, el índice (y su multichoice de las variantes y jerárquico),
entrada, el scroller. Cada unidad se asocia a una entidad subyacente de que el
volumen de la unidad se computa. La especificación de la entidad subyacente dicta el
tipo del objeto de que el volumen de una unidad se deriva (el ej., álbumes, artistas,...).
Cuando apropiado, pueden asociarse las unidades opcionalmente a un
seleccionador, es decir, la especificación de un juego de restricciones que determina
los casos reales de la entidad subyacente ser usado como el volumen de la unidad al
ejecutarse.
Traducción mía
Composition describes which pages compose the hypertext, and which content units
make up a page. The pages of the Web site are the containers of information actually
delivered to the reader. Units are atomic content elements used to publish the
information described in the data model. Seven types of units are predefined in
WebML to compose pages: data, multi-data, index (and its variants multichoice and
hierarchical), entry, scroller. Each unit is associated to one underlying entity, from
which the content of the unit is computed. The specification of the underlying entity
dictates the object type from which the content of a unit is derived (e.g., albums,
artists,...). When appropriate, units may be optionally associated to a selector, i.e., the
specification of a set of restrctions that determine the actual instances of the
underlying entity to be used as the content of the unit at runtime.
Página | 37
La navegación del sitio se especifica por los eslabones. Pueden definirse los
eslabones entre las unidades dentro de una sola página, entre unidades puestas en
las páginas diferentes, y entre las páginas. Se llama contexto de navegación a la
información llevada a lo largo de un eslabón. Se llaman eslabones contextuales a
aquellos que llevan la información, se llaman eslabones no-contextuales a los que no
tienen la información del contexto asociada. La información del contexto es
típicamente necesaria para asegurar la compatibilidad de unidades.
Traducción mía
Navigation of the site is specified thru links. Links can be defined between the units
inside a single page, between units placed in different pages, and between pages.
The information carried along a link is called navigation context, or simply context.
Links that carry context information are called contextual links, whereas links that have
no associated context information are called non-contextual links. Context information
is typically necessary to ensure the computability of units.
(Wikipedia-WebML, 2013)
La personalización declaratoria: el diseñador define los conceptos derivados
(ej., entidades, los atributos, los componentes multi-estimados) de quien la
definición depende de los datos específicos para el usuario. De esta manera, la
personalización se especifica declaratoriamente; el sistema rellena al modelo de
información para cada usuario al computar el volumen de unidades.
La personalización procesal: WebML incluye una sintaxis de XML para escribir
reglas comerciales que computan y guardan la información específica para el
usuario. Una regla comercial es un evento-condición-acción triple que especifica
el evento a ser supervisado la condición previa a ser verificada cuando el evento
ocurre, y la acción a ser tomada cuando la condición se encuentra verdadera.
Tareas típicas realizadas por las reglas comerciales son la asignación de usuarios
a grupos del usuario basados en información dinámicamente reunida, la
notificación de mensajes a los usuarios en la actualización de la base de
información (la tecnología del empujón), el registro de acciones del usuario en las
estructuras de los datos usuario-específicas, y así sucesivamente.
Página | 38
Traducción mía
Declarative personalization: the designer defines derived concepts (e.g.,
entities, attributes, multi-valued components) whose definition depends on user-
specific data. In this way, customization is specified declaratively; the system fills
in the information relative to each user when computing the content of units.
Procedural personalization: WebML includes an XML syntax for writing business
rules that compute and store user-specific information. A business rule is a triple
event-condition-action, which specifies the event to be monitored, the precondition
to be checked when the event occurs, and the action to be taken when the
condition is found true. Typical tasks performed by business rules are the
assignment of users to user groups based on dynamically collected information,
the notification of messages to users upon the update of the information base
(push technology), the logging of user actions into user-specific data structures,
and so on.
Traducción mía
Presentation is the orthogonal task of defining the look and feel of pages in a site
view. WebML does not include a specific model for expressing presentation at the
conceptual level, but leverages standard approaches, more familiar to graphic and
communication experts.
Since WebML specifications can be represented using XML, presentation is
considered like a document transformation mapping the WebML specification of a
page into a page written in a concrete implementation language like JSP or ASP.NET.
Consequently, presentation is addressed in WebML by attaching XSL style sheets to
site views, pages, units and unit subelements. XSL style sheets take in input WebML
specifications, coded as XML documents conforming to the WebML Document Type
Definition, and output page templates embodying the required mark-up code and data
access queries. An implementation of WebML may include several pre-defined
presentation style sheets and the server-side components supporting the data access
queries needed to populate the content of the page templates produced by the XSL
style sheets.
Página | 39
Figura 2.12 Ejemplo de Modelo de Presentación (tecnologimerlin, 2007)
Página | 40
Traducción mía
A typical design process using WebML proceeds by iterating the following steps for
each design cycle:
Requirements Collection. Application requirements are gathered, which
include the main objectives of the site, its target audience, examples of
content, style guidelines, required personalization and constraints due to
legacy data.
Data Design. The data expert designs the structural model, possibly by
reverse-engineering the existing logical schemas of legacy data sources.
Hypertext Design "in the large". The Web application architect defines the
structure "in the large" of the hypertext, by identifying pages and units, linking
them, and mapping units to the main entities and relationships of the structure
schema. In this way, he develops a "skeleton" site view, and then iteratively
improves it.
Hypertext Design "in the small". The Web application architect concentrates
next in the design "in the small" of the hypertext, by considering each page and
unit individually. At this stage, he may add non-contextual links between
pages, consolidate the attributes that should be included within a unit, and
introduce novel pages or units for special requirements (e.g., alternative index
pages to locate objects, filters to search the desired information, and so on).
Presentation Design. Once all pages are sufficiently stable, the Web style
architect adds to each page a presentation style.
User and Group Design. The Web administrator defines the features of user
profiles, based on personalization requirements. Potential users and user
groups are mapped to WebML users and groups, and possibly a different site
view is created for each group. The design cycle is next iterated for each of the
identified site views.
Página | 41
2.8.1 Java
Java es un lenguaje de programación con el que podemos realizar cualquier tipo de
programa. En la actualidad es un lenguaje muy extendido y cada vez cobra más importancia
tanto en el ámbito de Internet como en la informática en general.
Una de las principales características por las que Java se ha hecho muy famoso es que es
un lenguaje independiente de la plataforma. Eso quiere decir que si hacemos un programa
en Java podrá funcionar en cualquier ordenador del mercado. Es una ventaja significativa
para los desarrolladores de software, pues antes tenían que hacer un programa para cada
sistema operativo, por ejemplo Windows, Linux, Apple, etc. Esto lo consigue porque se ha
creado una Máquina de Java para cada sistema que hace de puente entre el sistema
operativo y el programa de Java y posibilita que este último se entienda perfectamente.
La independencia de plataforma es una de las razones por las que Java es interesante para
Internet, ya que muchas personas deben tener acceso con ordenadores distintos. Pero no se
queda ahí, Java está desarrollándose incluso para distintos tipos de dispositivos además del
ordenador como móviles, agendas y en general para cualquier cosa que se le ocurra a la
industria.
“Java es la base de casi todos los tipos de aplicaciones en red y el estándar global para el
desarrollo y suministro de aplicaciones móviles, juegos, contenido basado en web y software
de empresa. Con más de 9 millones de desarrolladores en todo el mundo, Java permite
desarrollar y desplegar de un modo eficiente interesantes aplicaciones y servicios. Con un
conjunto integral de herramientas, un ecosistema maduro y un sólido rendimiento, Java
ofrece portabilidad de aplicaciones incluso entre los entornos informáticos más dispares.”
(Oracle y Java _ Tecnologías _ Oracle ES)
2.8.2 PostgreSQL
(Martinez, 2010) Afirma
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido
bajo licencia BSD y con su código fuente disponible libremente. Es el sistema de
gestión de bases de datos de código abierto más potente del mercado y en sus
últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de
multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos
no afectará el resto y el sistema continuará funcionando.
Página | 42
Figura 2.14 Componentes de un sistema PostgreSQL (Martinez, 2010)
Página | 43
Java proporciona una gran cantidad de herramientas para desarrollar aplicaciones, pero
carece de medios para organizar los elementos. Normalmente es el arquitecto Java el que se
encarga de esta tarea pudiendo utilizar patrones.
Página | 44
El contexto se construye sobre la sólida base del núcleo. Así permite determinadas
configuraciones. Así la internacionalización, propagación de eventos, lectura de
recursos o la creación de contextos (como el web) formarán parte de este módulo.
El módulo JDBC otorga una capa de abstracción que elimina la necesidad de crear
código tedioso y trasforma las excepciones generadas por el proveedor de base de
datos.
El módulo ORM otorga una integración con los APIS más populares de ORM como
puedan ser JPA, JDO, Hibernate o iBatis.
Web
La capa web consiste en los módulos Web, Web-Servlet, Web-Struts y Web-Portlet.
AOP
El módulo AOP de Spring permite una implementación de programación orientada a
aspectos permitiendo definir métodos e interceptores, puntos de corte, etc. Para
desacoplar el código.
Página | 45
Él módulo de instrumentación otorga instrumentación de clases así como un cargador
de clases a ser usadas en determinadas aplicaciones de servidor.
Test
El módulo de test permite probar las aplicaciones de Spring y los componentes con
JUnit o TestNG. Permite la carga consistente de contextos de Spring. Así se permiten
objetos mock que prueban tu código de manera aislada. (p. 9-11)
Los requisitos del software son la base de las medidas de calidad. La falta de
concordancia con los requisitos es una falta de calidad.
La adopción de una buena política contribuye en gran medida a lograr la calidad del
software, pero no la asegura. Para el aseguramiento de la calidad es necesario su
control o evaluación.
Página | 46
Figura 2.16 Gestión de Calidad (Noriega Quintana, 2007)
2.9.1.1 Características
(Smartsys Cia Ltda, 2011) Afirma
El modelo establece diez características, seis que son comunes a las vistas interna y
externa y cuatro que son propias de la vista en uso.
A continuación se describen las características y subcaracterísticas propias de este
estándar que se encuentran dentro de las vistas interna y externa, las cuales
usaremos para evaluar el software de CMI.
Funcionalidad: capacidad del software de proveer los servicios necesarios para
cumplir con los requisitos funcionales.
Sub características:
o Idoneidad.- Hace referencia a que si el software desempeña las tareas para
las cuales fue desarrollado.
o Exactitud.- Evalúa el resultado final que obtiene el software y si tiene
consistencia a lo que se espera de él.
o Interoperabilidad.- Consiste en revisar si el sistema puede interactuar con
otro sistema independiente.
o Seguridad.- Verifica si el sistema puede impedir el acceso a personal no
autorizado.
Fiabilidad: capacidad del software de mantener las prestaciones requeridas del
sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.
Sub características:
o Madurez.- Se debe verificar las fallas del sistema y si muchas de estas han
sido eliminadas durante el tiempo de pruebas o uso del sistema.
Página | 47
o Recuperabilidad.- Verificar si el software puede reasumir el funcionamiento
y restaurar datos perdidos después de un fallo ocasional.
o Tolerancia a fallos.- Evalúa si la aplicación desarrollada es capaz de manejar
errores.
Usabilidad: esfuerzo requerido por el usuario para utilizar el producto
satisfactoriamente.
Sub características:
o Aprendizaje.- Determina que tan fácil es para el usuario aprender a utilizar el
sistema.
o Comprensión.- Evalúa que tan fácil es para el usuario comprender el
funcionamiento del sistema
o Operatividad.- Determina si el usuario puede utilizar el sistema sin mucho
esfuerzo.
o Atractividad.- Verifica que tan atractiva se ve la interfaz de la aplicación.
Eficiencia: relación entre las prestaciones del software y los requisitos necesarios
para su utilización.
Sub características:
o Comportamiento en el tiempo.- Verifica la rapidez en que responde el
sistema
o Comportamiento de recursos.- Determina si el sistema utiliza los recursos
de manera eficiente
Mantenibilidad: esfuerzo necesario para adaptarse a las nuevas especificaciones y
requisitos del software.
Sub características:
o Estabilidad.- Verifica si el sistema puede mantener su funcionamiento a pesar
de realizar cambios.
o Facilidad de análisis.- Determina si la estructura de desarrollo es funcional
con el objetivo de diagnosticar fácilmente las fallas.
o Facilidad de cambio.- Verifica si el sistema puede ser fácilmente modificado
o Facilidad de pruebas.- .- Evalúa si el sistema puede ser probado fácilmente
Portabilidad: capacidad del software ser transferido de un entorno a otro.
Sub características:
o Capacidad de instalación.- Verifica si el software se puede instalar
fácilmente
o Capacidad de reemplazamiento.- Determina la facilidad con la que el
software puede remplazar otro software similar.
o Adaptabilidad.- El software se puede trasladar a otros ambientes
o Co-Existencia.- El software puede funcionar con otros sistemas
Cada una de las características debe ser evaluada dentro del software basándonos
en pruebas de funcionamiento, medición de rendimiento y pruebas con usuarios que
harán uso del sistema.
Página | 48
“Las Pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo”. (Wikipedia-Pruebas, 2014)
2.10.1 Objetivos
El objetivo de las pruebas es presentar información sobre la calidad del producto a las
personas responsables de este.
Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más
variada. Esto hace que el proceso de "Testing" sea completamente dependiente del
Contexto en el que se desarrolla.
A pesar de lo que muchos promueven, no existen las "Mejores Prácticas" como tal. Toda
práctica puede ser ideal para una situación pero completamente inútil o incluso perjudicial en
otra.
Por esto, las actividades, técnicas, documentación, enfoques y demás elementos que
condicionaran las pruebas a realizar, deben ser seleccionados y utilizados de la manera más
eficiente según contexto del proyecto.
Pruebas Estáticas: Son el tipo de pruebas que se realizan sin ejecutar el código
de la aplicación.
Pruebas Dinámicas: Todas aquellas pruebas que para su ejecución requieren la
ejecución de la aplicación.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo de
forma que cada caso sea independiente del resto.
2.10.2.1 Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las
partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código
debe satisfacer.
Página | 49
• Constituye una buena forma de ejecutar pruebas de concepto. Cuando es
necesario hacer pruebas de conceptos sin integrar usar pruebas unitarias se
convierte en un método efectivo.
• Permite hacer refactoring tempranamente en el código. No es necesario todo un
ciclo de integración para hacer refactoring en la aplicación, basta con ver cómo se
comporta un caso de prueba para hacer refactoring unitario sobre la clase que
estamos probando en cuestión.
• Permite incluso hacer pruebas de estrés tempranamente en el código. Por
ejemplo un método que realice una consulta SQL que exceda los tiempos de
aceptación es posible optimizarla antes de integrar con la aplicación.
• Permite encontrar errores o bugs tempranamente en el desarrollo. Y está
demostrado Limitaciones
Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del
código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán
errores de integración, problemas de rendimiento y otros problemas que afectan a todo el
sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de
entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas
unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.
Herramientas
JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck. Se
encuentra basado en SUnit creado originalmente para realizar pruebas unitarias
para el lenguaje Smalltalk.
TestNG: Creado para suplir algunas deficiencias en JUnit.
JTiger: Basado en anotaciones, como TestNG.
SimpleTests: Entorno de pruebas para aplicaciones realizadas en PHP.
PHPUnit: Sistema para la realización pruebas unitarias en PHP.
CPPUnit: Versión del framework para lenguajes C/C++.
NUnit: Versión del framework para la plataforma.NET.
FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual FoxPro
MOQ: Entorno para la creación dinámica de objetos simuladores (mocks).
Página | 50
( )
1
“Estas ecuaciones se han obtenido por medio de ajustes de curvas realizado por Boehm en TRW
sobre 63 proyectos.” (Dolado)
Página | 51
Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo
orgánico, pero con diferentes constantes. Así, el coste se da por
1. Modo orgánico
2. Modo semiencajado
3. Modo empotrado
Página | 52
Estos atributos se agrupan en cuatro categorías: atributos del producto, atributos del
ordenador, atributos del personal y atributos del proyecto.
(Dolado) Afirma
1. Atributos del producto
RELY: garantía de funcionamiento requerida al software
DATA: tamaño de la base de datos
CPLX: complejidad del producto
2. Atributos del ordenador
TIME: restricción de tiempo de ejecución
STOR: restricción del almacenamiento principal
VIRT: volatilidad de la máquina virtual
TURN: tiempo de respuesta del ordenador
2. Atributos del personal
ACAP: capacidad del analista
AEXP: experiencia en la aplicación
PCAP: capacidad del programador
VEXP: experiencia en máquina virtual
LEXP: experiencia en lenguaje de programación
3. Atributos del proyecto
MODP: prácticas de programación modernas
TOOL: utilización de herramientas software
SCED: plan de desarrollo requerido.
Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo -- bajo --
nominal -- alto -- muy alto -- extremadamente alto.
(Dolado) Afirma
1. Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más
afectadas que otras por los atributos. El modelo detallado proporciona un conjunto
de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la
asignación del personal para cada fase del proyecto.
2. Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos
son módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado,
esto es, al nivel al que es más susceptible la variación.
Página | 53
y dura del 10% al 40% del tiempo nominal de desarrollo td. Estos porcentajes
dependen del modo y del tamaño (de 2000 LOC a 512000 LOC).
Diseño del producto. La segunda fase del ciclo de desarrollo COCOMO se
preocupa de la determinación de la arquitectura del producto y de las
especificaciones de los subsistemas. Esta fase requiere del 16% al 18% del
esfuerzo nominal Kn, y puede durar del 19% al 38% del tiempo nominal de
desarrollo td.
Programación. La tercera fase del ciclo de desarrollo COCOMO se subdivide en
dos subfases: diseño detallado y prueba del código. Esta fase requiere del 48% al
68% del esfuerzo nominal Kn, y dura del 24% Al 64% del tiempo nominal de
desarrollo.
Prueba/Integración. Esta última fase consiste principalmente en unir las diferentes
unidades ya probadas. Se utiliza del 16% al 34% del coste nominal Kn y dura del
18% al 34% del td.
B. Principio de estimación del esfuerzo.
Tamaño equivalente. Como parte del software puede haber sido ya desarrollado,
no se requiere entonces un desarrollo completo. En tales casos se estiman las
partes de diseño (D%), código (C%) e integración (I%) a ser modificadas. Se
calcula un factor de ajuste A
2
Ver Tabla 2.2
Página | 54
3 CAPITULO III
MARCO APLICATIVO
3.1 Introducción
En este capítulo se explicara en detalle los aspectos relacionados con la funcionalidad,
organización, descripción de funciones y diferentes procesos que existe en el departamento
de Recursos Humanos de la Empresa de Limpieza industrial TOTE’s LTDA.
3.2 Análisis
Se ha optado por la metodología extrema XP ya que esta se ajusta a las características del
proyecto y se basa en la metodología de modelado WebML.
Página | 55
a) Registro de personal: Registro del personal administrativo y de planta de la
empresa.
b) Control de asistencia: Gestión de usuarios, control de asistencia del personal.
c) Registro de documentación: Registro de documentación como ser: Certificados de
antecedentes, certificados médicos, documentos de garantía, etc.
d) Evaluación al personal, Informes, Memorándums: En casi de nuevas
designaciones se emitirán reportes de asistencia, así como también la emisión de
memorándums en forma automática.
3.3.2 Pruebas
Una de las principales aportaciones de esta metodología es el concepto de desarrollo por
tests (pruebas). Los tests son realizados a priori con el fin de prevenir errores, no de
solucionarlos. Esto confiere una gran cantidad de software resultante.
Los tests son ejecutados automáticamente cada día para asegurar que el sucesivo desarrollo
del sistema no afecta a su estabilidad. Dado que los tests son creados a priori fallaran hasta
que la funcionalidad esté implementada, en el proceso que comúnmente se llama rojo a
verde. En caso de que se encuentren fallos no detectados previamente.
3.3.4 Refactorización
En las sucesivas iteraciones ha sido necesario refactorizar partes del núcleo del sistema y
este proceso ha sido realmente sencillo, a lo que ha contribuido en gran parte la cantidad de
tests realizados.
Página | 56
3.3.8 Cliente en el equipo
Aunque esto estrictamente no se realiza dado la naturaleza del proyecto, la experiencia del
autor como personal antiguo de la empresa ayudo a entender los procesos a automatizar,
además que el cliente siempre estuvo en contacto con el autor mediante correo electrónico y
chat.
Se describe brevemente las características que el sistema debe tener desde la perspectiva
del cliente.
Administración de usuarios
El módulo se puede dividir en las siguientes historias de usuario y sus respectivas tareas:
Página | 57
Historia 1
Descripción:
Solo debe de asignarse como usuario a un funcionario activo que esté trabajando como
Jefe de Recursos Humanos, Administrador de Sistema, o Supervisor
Observaciones:
CONFIRMADO por el cliente
Tareas
Tabla 3.2 Diseñar la estructura de datos para registrar la información del usuario y funcionario
Tarea
Nombre de tarea: Diseñar la estructura de datos para registrar la información del usuario
y funcionario
Descripción:
Se realiza el diseño de la base de datos para la información del funcionario y del usuario.
Página | 58
Tabla 3.3 Tarea - Registro de datos del usuario
Tarea
Descripción:
Se desarrolla una interfaz para que se busque la información de un funcionario para
luego poderlo habilitar como usuario.
Tabla 3.4 Tarea - Habilitación de solo funcionarios activos para ser asignados como usuarios
Tarea
Nombre de tarea: Habilitación de solo funcionarios activos para ser asignados como
usuarios
Descripción:
Se desarrolla una interfaz para que se muestren solo a los funcionarios activos para que
solo estos puedan ser habilitados como usuarios del sistema.
Administración de funcionarios
El módulo se puede dividir en las siguientes historias de usuario y sus respectivas tareas:
Página | 59
Historia 2
Historia de Usuario
Descripción:
Diseñar el módulo de registro de funcionarios, y verificar si el funcionario a registrar ya
estaba trabajando con anterioridad en la empresa
Observaciones:
CONFIRMADO por el cliente
Tareas
Tarea
Descripción:
Se diseña la tabla que corresponde a la información del funcionario.
Página | 60
Tabla 3.7 Tarea - Modulo de registro de información de un funcionario
Tarea
Descripción:
Se desarrolla el modulo para el registro y habilitación de un nuevo funcionario.
Tarea
Descripción:
Se desarrolla el modulo para re afiliar a un funcionario que ya tiene almacenado datos
como un ex funcionario.
Página | 61
- Tarea 1: Diseñar la estructura de datos para registrar la información del
usuario y funcionario
- Tarea 2: Registro de datos del usuario
- Tarea 3: Habilitación de solo funcionarios activos para ser asignados como
usuarios
3
Ver anexos
Página | 62
3.5.1 Estimaciones de esfuerzo
Administración de Usuarios
Administración de funcionarios
Generación de Reportes
Página | 63
de los
funcionarios
6 Registrar 30/01/2014 19/02/2014
asistencias de los
funcionarios
Cuarta 7 Generar reportes 20/02/2014 26/03/2014
de planilla de
sueldos por
contrato
T3 13 T4 13 T1 14
Id. Nombre de tarea Comienzo Fin Duración
ago sep oct nov dic ene feb mar
Tarea 1.1: Diseñar la estructura de datos para registrar la información del usuario y
funcionario
Funcionario Persona
PK cod_funcionario PK ci
PK ci_exp
FK1 ci
FK1 ci_exp nombre1
fecha_nacimiento nombre2
lugar_nacimiento Es apellido_paterno
sexo apellido_materno
estado_civil profesion
fecha_expiracion_ci direccion
fecha_ingreso telefono_fijo
bachiller telefono_celular
enfermedad observaciones
numero_certificado_medico
fecha_certificado_medico
numero_certificado_ptj
fecha_certificado_ptj Usuario
grupo_sanguineo Autorizacion
peso_kg PK cod_usuario
altura_metros PK cod_autorizacion
color_ojos Es username De
nombre_banco_cuenta password authority
numero_cuenta_bancaria enabled FK1 cod_usuario
talla_uniforme FK1 cod_funcionario
numero_libreta_militar
actualmente_trabajando
nombre_afp
numero_cuenta_afp
numero_certificado_nacimiento
estudiante
numero_registro_caja_de_salud
nombre_caja_de_salud
cod_archivo
email
Figura 3.2: Estructura de datos para registrar la información del usuario y funcionario
Página | 64
Tarea 1.2: Diseñar la interfaz para que se busque la información de un funcionario para
luego poderlo habilitar como usuario.
Figura 3.3: Pantalla de búsqueda de funcionarios para posterior registro como funcionario
Tarea 1.3: Habilitación de solo funcionarios activos para ser asignados como usuarios
Página | 65
Figura 3.5: Mensaje de que no se puede registrar como usuario porque no se trata de un
funcionario activo
Figura 3.6: Pantalla de registro de usuario en caso de que el funcionario este en estado activo
Página | 66
b. Identificar los resultados que terminan la historia y los que permiten continuar
dentro la historia:
- La historia termina cuando se termina de registrar a un funcionario como
usuario.
- La historia termina cuando se pulsa el botón cancelar en cualquiera de sus
interfaces.
- La historia no permite continuar en ella, para registrar a otro usuario se debe
iniciar el proceso desde el principio de la historia.
c. Identificar los caminos de ejecución posibles:
- Comienza la historia cuando el administrador decide registrar a un nuevo
usuario en el sistema, si el funcionario es válido se le asigna un nombre de
usuario y una contraseña además de elegir el tipo de privilegios que tendrá
este usuario,
- Se valida los datos del funcionario y usuario.
- Se almacena y actualiza esta información en la base de datos.
- La historia termina cuando el usuario ha sido registrado exitosamente.
d. Asignar un conjunto de valores válidos y valores de entorno a cada camino de
ejecución para obtener el resultado esperado:
- El conjunto de valores válidos está dado por la información ya almacenada de
los funcionarios.
e. Eliminación de caminos redundantes:
- No se encontraron caminos redundantes.
Página | 67
Figura 3.8: Pantalla de inicio para verificar la existencia de un funcionario
Página | 68
Figura 3.10: Pantalla de anuncio de que el funcionario tiene datos almacenados
Página | 69
Figura 3.12: Modulo para la re afiliación del funcionario
Página | 70
d. Asignar un conjunto de valores válidos y valores de entorno a cada camino de
ejecución para obtener el resultado esperado:
- El conjunto de valores válidos está dado por la información ya almacenada de
los funcionarios y los introducidos por el jefe de recursos humanos.
e. Eliminación de caminos redundantes:
- No se encontraron caminos redundantes.
Página | 71
Figura 3.15: Modulo para el llenado de datos de un nuevo contrato
Figura 3.16: Modulo para el registro de un nuevo contrato pantalla de contrato registrado
Página | 72
Figura 3.17: Pantalla de búsqueda de un contrato cerrado
Página | 73
Figura 3.19: Pantalla de interfaz de apertura de un contrato
Página | 74
- La historia termina cuando se pulsa el botón cancelar en cualquiera de sus
interfaces.
- La historia no permite continuar en ella, para registrar a otro contrato se debe
iniciar el proceso desde el principio de la historia.
c. Identificar los caminos de ejecución posibles:
- Comienza la historia cuando el jefe de recursos humanos decide registrar a un
nuevo contrato en el sistema, si el contrato es no está registrado se procede a
mostrar la interfaz de llenado de datos.
- Si el contrato ya está registrado con un nombre similar se procede a mostrar
su interfaz de edición.
- Se almacena y actualiza esta información del contrato en la base de datos.
- La historia termina cuando el contrato ha sido registrado exitosamente.
d. Asignar un conjunto de valores válidos y valores de entorno a cada camino de
ejecución para obtener el resultado esperado:
- El conjunto de valores válidos está dado por la información ya almacenada de
los contratos y los introducidos por el jefe de recursos humanos.
e. Eliminación de caminos redundantes:
- No se encontraron caminos redundantes.
Funcionario Persona
PK cod_funcionario PK ci
PK ci_exp
FK1 ci
FK1 ci_exp nombre1
fecha_nacimiento nombre2
lugar_nacimiento Es apellido_paterno
sexo apellido_materno
estado_civil profesion
fecha_expiracion_ci direccion
fecha_ingreso telefono_fijo
bachiller telefono_celular
enfermedad observaciones
numero_certificado_medico
fecha_certificado_medico
numero_certificado_ptj
Documento
fecha_certificado_ptj
grupo_sanguineo PK cod_documento
peso_kg Tiene
altura_metros archivo
color_ojos descripcion
nombre_banco_cuenta FK1 cod_funcionario
numero_cuenta_bancaria
talla_uniforme
numero_libreta_militar
actualmente_trabajando
nombre_afp
numero_cuenta_afp
numero_certificado_nacimiento
estudiante
numero_registro_caja_de_salud
nombre_caja_de_salud
cod_archivo
email
Página | 75
Tarea 4.2: Modulo de registro de documentos del funcionario.
Página | 76
Figura 3.24: Pantalla de descarga de documentos digitalizados
Página | 77
e. Eliminación de caminos redundantes:
- No se encontraron caminos redundantes.
PK,FK1 ci PK ci PK cod_regional
PK,FK1 ci_exp PK ci_exp
PK cod_funcionario nombre_regional
nombre1 observaciones
fecha_nacimiento nombre2
lugar_nacimiento Es apellido_paterno
sexo apellido_materno
estado_civil profesion
Contrato
fecha_expiracion_ci direccion
fecha_ingreso telefono_fijo PK cod_contrato
bachiller telefono_celular
enfermedad observaciones nombre_contrato
numero_certificado_medico direccion
fecha_certificado_medico Supervisor observaciones
numero_certificado_ptj activo
fecha_certificado_ptj PK cod_supervisor fecha_apertura
grupo_sanguineo Es supervisado por fecha_cierre
peso_kg Es activado motivo_cierre
altura_metros FK1 cod_funcionario FK1 cod_regional
color_ojos FK1 ci FK2 cod_supervisor
nombre_banco_cuenta FK1 ci_exp
numero_cuenta_bancaria
talla_uniforme Asistencia_mes Del
numero_libreta_militar
actualmente_trabajando PK cod_asistencia_mes
nombre_afp Puesto
numero_cuenta_afp total_faltas
total_atrasos PK cod_puesto
numero_certificado_nacimiento Del
estudiante FK2 cod_funcionario
cod_contrato hora_ingreso1
numero_registro_caja_de_salud
horas_trabajo hora_salida1
nombre_caja_de_salud
dias_laborables hora_ingreso2
cod_archivo Cargo
mes hora_salida2
email
gestion PK cod_cargo FK1 cod_cargo
observaciones FK2 cod_contrato
Tiene
FK1 cod_puesto nombre_cargo observaciones
FK2 ci descripcion vacante
FK2 ci_exp sueldo_base activado
fecha_alta
fecha_baja
Tarea 5.2: Modulo de verificación de asistencia del funcionario por contratos y general.
Figura 3.26: Pantalla delo listado de asistencias registradas de los funcionarios de un contrato
Página | 78
a. Identificar todos los posibles resultados de la historia:
- Interfaz para el listado de asistencias de los funcionarios de un contrato.
b. Identificar los resultados que terminan la historia y los que permiten continuar
dentro la historia:
- La historia termina cuando se lista las asistencias de los últimos tres meses.
- La historia permite continuar si es que el usuario desea ver registros de
asistencias anteriores.
c. Identificar los caminos de ejecución posibles:
- Comienza la historia cuando el supervisor decide listar el estado del registro
de las asistencias de un determinado contrato que este supervisando.
- Si el Supervisor decide ver registros de meses anteriores, se muestra el
listado correspondiente.
- La historia termina cuando decide continuar con otro modulo.
d. Asignar un conjunto de valores válidos y valores de entorno a cada camino de
ejecución para obtener el resultado esperado:
- El conjunto de valores válidos está dado por la información ya almacenada de
las asistencias de los funcionarios y los contratos abiertos.
e. Eliminación de caminos redundantes:
- No se encontraron caminos redundantes.
Figura 3.27: Diseño del formulario para el registro de asistencias de los funcionarios que
trabajaron en un respectivo contrato
Página | 79
Figura 3.28: Pantalla de inicio mostrando el estado del registro de las asistencias de los
contratos supervisados
Figura 3.29: Modulo del llenado de datos de las asistencias para un contrato en particular
Página | 80
Figura 3.30: Estado del listado de asistencias después del registro de datos
Página | 81
Figura 3.31: Diseño preliminar del reporte de la planilla por contratos
Página | 82
Figura 3.33: Reporte de la planilla del mes
Página | 83
3.7 Diagrama Jerárquico del sistema
Sistema de Control y
Administración de Recursos
Humanos TOTE’s LTDA
Sub Modulo
Sub Modulo Sub Modulo Sub Modulo
Contratos
Usuarios Regionales Asistencias
Supervisados
Página | 84
Persona Garante
Documento
-nombre1 -telefono_oficina
-descripcion
-nombre2 -relacion_con_el_funcionario
-archivo
-ci -...
-...
-direccion
-...
*
*
Funcionario Fotografia
-telefono_celular -codigo
-profesion -imagen
-... * -...
1111
*
* 1 Historial
-tipo
Contrato -descripcion
-nombre_contrato -fecha
Supervisor 1 -direccion -...
1 -...
-codigo
-identificador
-...
* 1 *
Tabla 3.14 Acceso de los usuarios a los diferentes módulos del sistema
Página | 85
funcionario
Editar datos personales
Editar documentos personales
Editar fotografía
Editar regional
Adicionar cargo
Cambiar de cargo
Eliminar cargo
Dar de baja de la empresa
Administrar garantes del
funcionario
Administrar documentos digitales
del funcionario
Contratos Buscar contrato
Listar contratos
Registrar contrato
Mostrar información de un
contrato
Actualizar supervisor
Editar datos del contrato
Editar logo de la empresa a la cual
pertenece el contrato
Cerrar contrato
Administrar puestos del contrato
Cargos Listar cargos
Registrar cargos
Mostrar datos del contrato
Editar datos del contrato
Puestos Listar puestos vacantes
Planillas Listar planillas
Generar planillas
Mostrar planillas generadas
Sesión Cambiar su propia contraseña
Supervisor Contratos Buscar contrato
Listar contratos supervisados
Mostrar información del contrato
Administrar asistencias del
contrato
Asistencias Registrar asistencias
Sesión Cambiar su propia contraseña
Página | 86
3.8 Modelado del sistema
Funcionario Funcionarios_Garantes Garante
PK,FK1 ci Persona
PK,FK1 cod_funcionario PK cod_garante
PK,FK1 ci_exp PK,FK2 cod_garante PK ci
PK cod_funcionario telefono_oficina PK ci_exp
relacion_funcionario_garante lugar_de_trabajo
fecha_nacimiento FK1 ci FK1 ci nombre1
lugar_nacimiento FK1 ci_exp FK1 ci_exp nombre2
sexo apellido_paterno
estado_civil apellido_materno
fecha_expiracion_ci profesion
fecha_ingreso direccion
bachiller Es
telefono_fijo
enfermedad telefono_celular
numero_certificado_medico observaciones
fecha_certificado_medico
numero_certificado_ptj
fecha_certificado_ptj
grupo_sanguineo Documentos
peso_kg
altura_metros Tiene PK cod_documento
color_ojos
nombre_banco_cuenta archivo Autorizacion
numero_cuenta_bancaria descripcion PK cod_autorizacion
Fotografias
talla_uniforme FK1 cod_funcionario
numero_libreta_militar PK cod_fotografia FK1 ci username
actualmente_trabajando Tiene FK1 ci_exp authority
nombre_afp imagen FK1 cod_usuario
numero_cuenta_afp FK1 cod_funcionario
numero_certificado_nacimiento FK1 ci
estudiante Historiales FK1 ci_exp
numero_registro_caja_de_salud
nombre_caja_de_salud PK contenido
cod_archivo
cod_historial Registros
email
fecha Tiene
PK cod_registro
tipo
FK1 cod_funcionario
FK1 cod_usuario
FK1 ci
descripcion
FK1 ci_exp
fecha hora
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
4
Figura 3.36 Modelo estructural
4
Ver Marco teórico, punto 2.7.1 Modelo estructural
Página | 87
Buscar Buscando Registrar a un Funcionario
Si existe
Funcionario Funcionario como Usuario
No
Inicio
Fin
Funcionario Funcionarios_Garantes Garante apellido_paterno
PK,FK1 ci Persona
PK,FK1 cod_funcionario PK cod_garante
PK,FK1
PK
ci_exp
cod_funcionario
PK,FK2 cod_garante
telefono_oficina
actualmente_trabajando
PK
PK
ci
ci_exp
relacion_funcionario_garante lugar_de_trabajo
fecha_nacimiento FK1 ci FK1 ci nombre1
lugar_nacimiento FK1 ci_exp FK1 ci_exp nombre2
sexo apellido_paterno
estado_civil apellido_materno
fecha_expiracion_ci profesion
fecha_ingreso direccion
bachiller Es
telefono_fijo
enfermedad telefono_celular
numero_certificado_medico observaciones
fecha_certificado_medico
numero_certificado_ptj
fecha_certificado_ptj
Registrando
grupo_sanguineo
peso_kg
altura_metros Tiene PK
Documentos
cod_documento
Usuario
color_ojos
nombre_banco_cuenta archivo Autorizacion
numero_cuenta_bancaria descripcion PK cod_autorizacion
Fotografias
talla_uniforme FK1 cod_funcionario
numero_libreta_militar PK cod_fotografia FK1 ci username
actualmente_trabajando Tiene FK1 ci_exp authority
nombre_afp imagen FK1 cod_usuario
numero_cuenta_afp FK1 cod_funcionario
numero_certificado_nacimiento FK1 ci
estudiante Historiales FK1 ci_exp
numero_registro_caja_de_salud
nombre_caja_de_salud PK contenido
cod_archivo
cod_historial Registros
email
Tiene
FK1
fecha
tipo
cod_funcionario
PK cod_registro
Fin
FK1 cod_usuario
FK1 ci
descripcion
FK1 ci_exp
fecha hora
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
5
Figura 3.37 Modelo de derivación (Registrar Usuario)
formulario de formulario de
buscando Si no esta Registrando
registro de datos de registro
funcionario registrado funcionario
funcionario de funcionario
Inicio
Si esta
ci registrado cod_regional
ci_exp
Mostrando
Fin
funcionario
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
5
Ver Marco teórico, punto 2.7.2 Modelo de Derivación
Página | 88
Formulario de
Registrando
registro de un
Contrato
contrato
Inicio
cod_regional
Funcionario Funcionarios_Garantes Garante
PK,FK1 ci Persona
PK,FK1 cod_funcionario PK cod_garante
PK,FK1 ci_exp PK,FK2 cod_garante PK ci
PK cod_funcionario telefono_oficina PK ci_exp
relacion_funcionario_garante lugar_de_trabajo
fecha_nacimiento FK1 ci FK1 ci nombre1
lugar_nacimiento FK1 ci_exp FK1 ci_exp nombre2
sexo apellido_paterno
estado_civil apellido_materno
fecha_expiracion_ci profesion
fecha_ingreso direccion
bachiller Es
telefono_fijo
enfermedad telefono_celular
numero_certificado_medico observaciones
fecha_certificado_medico
numero_certificado_ptj
fecha_certificado_ptj
grupo_sanguineo Documentos
peso_kg
altura_metros Tiene PK cod_documento
color_ojos
nombre_banco_cuenta archivo Autorizacion
numero_cuenta_bancaria descripcion PK cod_autorizacion
Fotografias
talla_uniforme FK1 cod_funcionario
numero_libreta_militar PK cod_fotografia FK1 ci username
actualmente_trabajando Tiene FK1 ci_exp authority
nombre_afp imagen FK1 cod_usuario
numero_cuenta_afp FK1 cod_funcionario
numero_certificado_nacimiento FK1 ci
estudiante Historiales FK1 ci_exp
numero_registro_caja_de_salud
nombre_caja_de_salud PK contenido
cod_archivo
cod_historial Registros
email
fecha Tiene
PK cod_registro
tipo
FK1 cod_funcionario
FK1 cod_usuario
FK1 ci
descripcion
FK1 ci_exp
fecha hora
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
Página | 89
Formulario de
formulario para buscando Mostrar Registrando
Si existe registro de
buscar contrato Contrato asistencia
asistencia
Inicio
Si no
existe cod_contrato
nombre_contrato
cod_funcionario
fin Fin
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
Generando y
Formulario para Buscando Mostrar Formulario para
Si existe registrando Mostrar Planilla
buscar contrato contrato Contrato generar planilla
planilla
Inicio No
datos de la
asistencia Fin
fin
Funcionario Funcionarios_Garantes Garante
PK,FK1 ci Persona
PK,FK1 cod_funcionario PK cod_garante
PK,FK1 ci_exp PK,FK2 cod_garante PK ci
PK cod_funcionario telefono_oficina PK ci_exp
relacion_funcionario_garante lugar_de_trabajo
fecha_nacimiento FK1 ci FK1 ci nombre1
lugar_nacimiento FK1 ci_exp FK1 ci_exp nombre2
sexo apellido_paterno
estado_civil apellido_materno
fecha_expiracion_ci profesion
fecha_ingreso direccion
bachiller Es
telefono_fijo
enfermedad telefono_celular
numero_certificado_medico observaciones
fecha_certificado_medico
numero_certificado_ptj
fecha_certificado_ptj
grupo_sanguineo Documentos
peso_kg
altura_metros Tiene PK cod_documento
color_ojos
nombre_banco_cuenta archivo Autorizacion
numero_cuenta_bancaria descripcion PK cod_autorizacion
Fotografias
talla_uniforme FK1 cod_funcionario
numero_libreta_militar PK cod_fotografia FK1 ci username
actualmente_trabajando Tiene FK1 ci_exp authority
nombre_afp imagen FK1 cod_usuario
numero_cuenta_afp FK1 cod_funcionario
numero_certificado_nacimiento FK1 ci
estudiante Historiales FK1 ci_exp
numero_registro_caja_de_salud
nombre_caja_de_salud PK contenido
cod_archivo
cod_historial Registros
email
fecha Tiene
PK cod_registro
tipo
FK1 cod_funcionario
FK1 cod_usuario
FK1 ci
descripcion
FK1 ci_exp
fecha hora
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
Página | 90
Menu
Administrador
BD de Usuarios
BD de Usuarios
BD del Sistema
BD de Regionales
6
Figura 3.43 Modelo de hipertexto (Administrador)
Menu Jefe de
Recursos
Humanos
BD de Usuarios
BD de Funcionarios
BD de Items
BD de Asistencias
Items
Documentos
Asistencias
Planilla
Contrato
6
Ver punto 2.7.3 Modelo de Hipertexto (Marco Teórico)
Página | 91
Menu Supervisor
BD de Usuarios
BD de Funcionarios
BD de Asistencias
BD del Sistema
BD de Contratos
Usuario
Es PK cod_usuario
username
Es Regional password
Supervisor Contrato enabled
PK cod_regional FK1 cod_funcionario
PK cod_supervisor PK cod_contrato FK1 ci
nombre_regional FK1 ci_exp
activado Es supervisado por nombre_contrato observaciones
FK1 cod_funcionario direccion
FK1 ci observaciones
FK1 ci_exp activo
fecha_apertura
fecha_cierre
Jefe de Recursos Humanos
motivo_cierre
Logos FK1 cod_regional
FK2 cod_supervisor
PK cod_logo
Asistencia_mes Del
PK cod_asistencia_mes imagen
FK1 cod_contrato Puesto
total_faltas PK cod_puesto
total_atrasos
FK2 cod_funcionario hora_ingreso1
cod_contrato hora_salida1 Cargo
horas_trabajo hora_ingreso2
dias_laborables hora_salida2 PK cod_cargo
mes Del
FK1 cod_cargo Tiene
gestion FK2 cod_contrato nombre_cargo
observaciones observaciones descripcion
FK1 cod_puesto vacante sueldo_base
FK2 ci activado
FK2 ci_exp fecha_alta
fecha_baja
Supervisor
7
Figura 3.46 Modelo de Presentación
7
Ver punto 2.7.3.4 Modelo de Presentación (Marco Teórico)
Página | 92
4 CAPÍTULO IV
MÉTRICAS DE CALIDAD
En este capítulo se tiene como objetivo el de aplicar las métricas de calidad para evaluar el
proyecto.
4.1 Introducción
Para evaluar este proyecto se aplican las métricas de calidad según el estándar ISO 9126,
evaluándose la fiabilidad, funcionabilidad, portabilidad, usabilidad y mantenimiento del
sistema.
4.2 Fiabilidad
Durante la entrega de los prototipos realizados en las cuatro iteraciones se encontraron las
siguientes deficiencias. A los mismos que necesitaron de un tiempo de servicio determinado.
Se logra levantar la siguiente información que se muestra en la siguiente tabla:
Tiempo
Tiempo de Numero de Fallas Probabilidad
medio entre
servicio peticiones encontradas de fallo
fallos
8 horas 25 1 0,04 8
16 horas 50 2 0,04 8
32 horas 80 3 0,0375 10,7
64 horas 160 5 0,03125 12,8
TOTAL 0,149 39,5
Por lo tanto el valor promedio de fallas producidas en un tiempo de servicio (PFTS) es de:
Lo que indica que el sistema es promedio puede presentar aproximadamente 37 fallas cada
mil peticiones.
Lo cual indica que el sistema presenta una falla en promedio cada 9.875 horas en el que se
hace el uso del sistema.
Entonces se tiene:
( ) ( ) ( )
Página | 93
Lo que nos indica que el sistema de control y administración de recursos humanos TOTE’s
LTDA tiene la capacidad de ser utilizado libre de errores con un 96.28% de seguridad y con
una probabilidad de que suceda una falla cada 25 peticiones.
Tabla 4.2 Análisis de la fiabilidad
Es conveniente hacer notar que estos datos fueron levantados en la etapa de las iteraciones
y con el transcurso del tiempo el mismo tenderá a no presentar fallas haciendo de la
fiabilidad una cualidad del software, es así que se vuelve a levantar los datos en la
finalización del proyecto según la metodología y se obtienen los siguientes datos:
Tiempo
Tiempo de Numero de Fallos Propabilidad
medio entre
servicio peticiones encontrados de fallo
fallos
8 horas 25 1 0,04 8
16 horas 50 1 0,02 16
32 horas 80 1 0,0125 32
64 horas 160 2 0,0125 32
TOTAL 0,085 88
( ) ( ) ( )
Lo que nos indica que el sistema web de control y administración de recursos humanos para
la empresa TOTE’s LTDA tiene la capacidad de ser utilizado libre de errores con un 97.87%
de seguridad.
Página | 94
4.3 Funcionabilidad
Se hace uso de las métricas de adecuación funcional y completitud de la implementación
funcional que nos ayuda a medir la implementación funcional y que tan adecuadas son las
funciones evaluadas.
( )
( )
Lo que nos indica que falta un 57% del sistema por implementar.
( )
( )
( )
( )
( )
( )
Lo que nos indica que existe un 71,4% de adecuación de las historias de usuario evaluadas
en la fase de producción.
Página | 95
Tabla 4.5 Análisis de la funcionabilidad
( )
( )
4.4 Usabilidad
Entendido como la operabilidad y la capacidad de ser comprendido, cuyas métricas son la
consistencia operacional en el uso y la completitud de la descripción.
Consistencia operacional
( )
( )
Página | 96
Por lo tanto tenemos que un 95,2% del sistema no tiene instancias de operaciones con
comportamiento inconsistente.
( )
( )
Consistencia operacional
( )
( )
Página | 97
Consistencia operacional en el uso
( )
( )
Tabla 4.8 Mejora en la usabilidad del sistema
4.5 Portabilidad
La portabilidad del sistema viene dada de la siguiente manera:
( )
( )
Lo cual indica que el sistema web tiene una facilidad de instalación de un 75% un valor
satisfactorio para el factor de portabilidad.
Página | 98
( )
( )
4.6 Mantenimiento
Capacidad para ser analizado: El sistema web tiene la capacidad para ser diagnosticado,
para identificar las partes que han de ser modificadas si fuera el caso.
Todos los valores obtenidos están dentro de los márgenes de los estándares de calidad ISO
9126.8. Por lo tanto se concluye que la valoración que se obtuvo alcanzo una calidad del
94.22% lo cual representa un grado de satisfacción.
Costo de desarrollo del software, costo de capacitación del usuario y costo del software base
para la construcción del sistema.
8
Ver Marco Teórico, punto 2.9.1 ISO 9126
Página | 99
La obtención de este precio se realizó sobre la base del método de estimación empírica
COCOMO9 básico, que estima el esfuerzo E expresada en personas-mes y el tiempo de
duración del desarrollo del software Td, mediante las siguiente ecuaciones.
Dadas las características del software, se pueden afirmar que el mismo está comprendido
entre el grupo de sistemas Semi encajado.
Luego
9
Ver Marco teórico, punto 2.11 El modelo COCOMO
10
Ver Marco teórico, Tabla 2.2 Coeficientes
Página | 100
Costo de la capacitación de los usuarios
Este costo está dado por producto del tiempo de capacitación, dos horas a 50 Bs (25 Bs la
hora), por el número de días de capacitación que en este caso fueron 5, hacen un total de:
Página | 101
5 CAPÍTULO V
CONCLUSIONES Y
RECOMENDACIONES
5.1 Conclusiones
Después de terminar el desarrollo del sistema para el departamento de Recursos Humanos
se llegaron a las siguientes conclusiones
Cabe hacer notar que los resultados obtenidos en las métricas de calidad fueron tomados en
la etapa de las iteraciones siendo así de manera preliminar, y se espera una mejora en los
datos obtenidos a partir del conjunto de datos que serán registrados en la base de datos del
sistema.
5.2 Recomendaciones
Las recomendaciones que se pueden realizar para futuros proyectos basados en este están
referidas a continuación:
Se puede ampliar el sistema de tal forma que se pueda implementar un sistema que utilice
los datos especialmente de asistencia para sugerir asensos futuros y dar baja de
funcionarios que son informales en sus asistencias.
El sistema web está orientado según las necesidades de la empresa en la cual los horarios
de trabajo son diversos, habiendo horarios de 2, 4, 8, incluso 12 horas de trabajo y una
complejidad es que los funcionarios no están en solo ambiente de trabajo (contrato), se
sugiere que en un futuro se adecue el uso de relojes biométricos inalámbricos y que se
Página | 102
recupere la información de este y se los suba vía web mediante el sistema para que las
asistencias sean mejor controladas.
El sistema está orientado a la Web y puede ser ejecutado por dispositivos móviles como ser
celulares inteligentes con navegadores, pero se sugiere que en un futuro se realice una
aplicación exclusiva para estos dispositivos para mejorar la conectividad y la interfaz que
existe con el usuario y el sistema en conjunto.
Página | 103
6 BIBLIOGRAFÍA
Anaya, A. (s.f.). A propósito de programación extrema XP (eXtreme Programming). Popayan
– Cauca - Colombia.
Ceballos, F., Arboleda, H., & Casallas, R. (30 de Noviembre de 2008). Un Enfoque para
Desarrollar Aplicaciones WEB Basado en Líneas de Producto Dirigidas por Modelos.
Recuperado el 14 de Septiembre de 2014, de Revista electrónica Paradigma en
construcción de software:
http://paradigma.uniandes.edu.co/index.php?option=com_content&view=article&catid
=47%3Aarticulos&id=110%3Aun-enfoque-para-desarrollar-aplicaciones-web-basado-
en-lineas-de-producto-dirigidas-por-modelos&lang=es&showall=1
Página | 104
Oracle y Java _ Tecnologías _ Oracle ES. (s.f.). Recuperado el 14 de Septiembre de 2014,
de Oracle España _ Hardware and Software, Engineered to Work Together:
www.oracle.com/es/technologies/java/overview/index.html#readmore
Smartsys Cia Ltda. (1 de Septiembre de 2011). Norma ISO-9126 para análisis de software.
Recuperado el 14 de Septiembre de 2014, de BEMUS ERP - Su plataforma PYME
Norma ISO-9126 para análisis de software:
http://bemuserp.blogspot.com/2011/09/norma-iso-9126-para-analisis-de.html
Sommerville, I. (2005). Ingeniería del Software (Septima ed.). Madrid - España: Pearson
Education S. A.
Página | 105
ANEXOS
Página | 106
Historia 3
Historia de Usuario
Descripción:
Diseñar el módulo de registro de contratos
Observaciones:
CONFIRMADO por el cliente
Tareas
Tarea
Descripción:
Se diseña la tabla que corresponde a la información del contrato.
Tarea
Página | 107
Tipo de tarea: Desarrollo Puntos estimados: 1
Descripción:
Se desarrolla el modulo para el registro y habilitación de un nuevo contratos.
Tarea
Descripción:
Se desarrolla el modulo para re abrir un contrato que ya estaba registrado en el sistema
pero que se cerró con anterioridad.
Historia 4
Historia de Usuario
Descripción:
Diseñar el módulo de registro de documentación del funcionario
Página | 108
Observaciones:
CONFIRMADO por el cliente
Tareas
Tarea
Descripción:
Se diseña las tabla que corresponden a la información de la documentación del
funcionario, como ser copias digitales (copias escaneadas) almacenadas en la base de
datos.
Tarea
Descripción:
Se desarrolla el modulo para el registro y almacenamiento en la base de datos de los
documentos digitalizados de un funcionario.
Página | 109
Tabla 6.8 Tarea - Modulo de descarga de documentos digitalizados
Tarea
Descripción:
Se desarrolla el modulo para descargar documentos que ya están almacenados en la
base de datos.
Historia 5
Tabla 6.9 Historia de usuario - Verificar el estado de las asistencias de los funcionarios
Historia de Usuario
Descripción:
Diseñar el módulo para reportar asistencias de los funcionarios
Observaciones:
CONFIRMADO por el cliente
Tareas
Página | 110
Tabla 6.10 Tarea - Diseño de la base de datos para la información de las asistencias de un
funcionario
Tarea
Descripción:
Se diseña las tablas que corresponden a la información de la asistencia del funcionario.
Tabla 6.11 Tarea - Modulo de verificación de asistencias de los funcionarios por contratos y
general
Tarea
Descripción:
Se desarrolla el modulo para mostrar las asistencias de un funcionario por contrato y su
asistencia general.
Historia 6
Historia de Usuario
Página | 111
Nombre de Historia: Registrar asistencias de los funcionarios
Descripción:
Diseñar el módulo para registrar las asistencias de los funcionarios
Observaciones:
CONFIRMADO por el cliente
Tareas
Tabla 6.13 Tarea - Diseño del formulario para el registro de las asistencias
Tarea
Descripción:
Se diseña el formulario para que el supervisor registre la asistencia del funcionario.
Tabla 6.14 Modulo de verificación de asistencias de los funcionarios por contrato y general
Tarea
Página | 112
Descripción:
Se desarrolla el modulo para registrar la asistencia de un funcionario.
Generación de Reportes
El módulo se puede dividir en las siguientes historias de usuario y sus respectivas tareas:
Historia 7
Tabla 6.15 Historia de usuario - Generar reportes de planilla de sueldos por contrato
Historia de Usuario
Descripción:
Diseñar el módulo para generar las planillas de sueldo por contrato
Observaciones:
CONFIRMADO por el cliente
Tareas
Tarea
Descripción:
Se diseña el formato del reporte que se generara.
Página | 113
Tabla 6.17 Tarea - Modulo de generación de reportes de planilla de sueldos
Tarea
Descripción:
Se desarrolla el modulo para generar la planilla preliminar de sueldos por contratos.
Página | 114
Página | 115
Página | 116
Matriz del Marco Lógico
Página | 117
documentación orientado a la Encuestas con el Personal
del personal, así Web capaz de personal para capacitado y
como también realizar reportes conocer el grado calificado.
controle los diarios de de satisfacción Seguridad y
permisos y faltas personal. de uso del resguardo del
del personal Incremento en la Sistema. servidor de la
operativo y efectividad del Documentación Base de Datos.
administrativo. personal. del Sistema.
Elaborar un Personal Evaluaciones
módulo que capacitado para periódicas.
generar reportes, el manejo del
informes e sistema de
historial de información.
asistencias del
personal
operativo y
administrativo.
Elaborar un
módulo que
genere reportes e
informes sobre el
estado de los
contratos y el
personal
existente y
faltante en cada
una de las
instituciones a las
que se brinda el
servicio de
limpieza
industrial.
PLAN DE 7 meses para la Presentación del El Personal es
ACTIVIDADES: realización del perfil del proyecto receptivo a la
Identificar el proyecto. de grado implementación
problema Gastos de realizado durante del Sistema de
principal. transporte al tres meses. Información en la
Página | 118
Elaborar el árbol visitar a la Aval del Asesor Empresa.
de problemas. Empresa de aprobando el La Empresa
Elaborar el árbol Limpieza contenido del mantiene interés
de objetivos. Industrial perfil de proyecto en el desarrollo
Elaborar la Matriz “TOTES LTDA”. de grado. del sistema.
del marco Lógico. Aval de la La gerencia
Elaborar del Empresa aprueba el
Perfil de proyecto aprobando el presupuesto del
de grado. desarrollo del proyecto.
Determinación de sistema. Las terminales y
Requerimientos Códigos fuentes el servidor
(1ra iteración). de los módulos trabajen
Diseñar el desarrollados. adecuadamente.
módulo de Pruebas para la
interacción. capacitación al
Desarrollar el personal.
Sistema de Manuales de
Información para usuario.
la Administración Encuestas
de Personal (1ra realizadas a los
iteración). usuarios.
Codificar el Informe del
software para el revisor del
sistema de sistema.
información (1ra
iteración).
Implementar el
sistema y utilizar
los casos de
prueba (1ra
iteración).
Determinación de
Requerimientos
(2da iteración).
Desarrollar el
Sistema de
Información para
Página | 119
el Control de
Personal (2da
iteración).
Codificar el
software del
Sistema de
Información (2da
iteración).
Implementar el
sistema de
información y
utilizar los casos
de prueba (2da
iteración).
Elaboración de
los manuales de
Usuario.
Capacitación del
personal para la
puesta en
marcha del
sistema de
información.
Entrega Final del
Sistema de
Información a la
Empresa.
Página | 120
DOCUMENTOS
Página | 121