Sistema Web para mejorar la Gestión del Registro de pago de horas extraordinarias en la CNEL by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas SISTEMA WEB PARA MEJORAR LA GESTIÓN DEL REGISTRO DE PAGO DE HORAS EXTRAORDINARIAS EN LA CORPORACIÓN NACIONAL DE ELECTRICIDAD-EMPRESA PÚBLICA SANTO DOMINGO; PERIODO 2017-2018

Trabajo de Titulación previo a la obtención del título de Ingeniero de Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software.

Autores: LUIS FERNANDO AREQUIPA VELÁSQUEZ BRYAN GONZALO MEZA BARRERA Director: MG. LUIS JAVIER ULLOA MENESES Santo Domingo – Ecuador Agosto, 2018

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

HOJA DE APROBACIÓN SISTEMA WEB PARA MEJORAR LA GESTIÓN DEL REGISTRO DE PAGO DE HORAS EXTRAORDINARIAS EN LA CORPORACIÓN NACIONAL DE ELECTRICIDAD-EMPRESA PÚBLICA SANTO DOMINGO; PERIODO 2017-2018 Línea de Investigación: Estudio, Diseño e Implementación de Software. Autor: LUIS FERNANDO AREQUIPA VELÁSQUEZ BRYAN GONZALO MEZA BARRERA

Luis Javier Ulloa Meneses, Mg. f. DIRECTOR DE LA DISERTACIÓN DE GRADO

Fausto Ernesto Orozco Iguasnia, Mg. CALIFICADOR

Margareth Viviana Hurtado Quiroz, Mg. CALIFICADOR

Luis Javier Ulloa Meneses, Mg DIRECTORA DE LA ESCUELA DE SISTEMAS

Santo Domingo – Ecuador Agosto, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Yo, Luis Fernando Arequipa Velásquez portador de la cédula de ciudadanía Nº 2300469281 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legar y académica.

LUIS FERNANDO AREQUIPA VELÁSQUEZ CI 2300469281

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD Yo, Bryan Gonzalo Meza Barrera portador de la cédula de ciudadanía Nº 1715710941 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legar y académica.

BRYAN GONZALO MEZA BARRERA CI 1715710941

AGRADECIMIENTO Doy gracias a Dios por permitirme lograr cumplir metas a lo largo de mi carrera, a mis padres los cuales fueron un gran apoyo incondicional moral y económico, a mi abuelita la cual estuvo allí siempre pendiente de mi desempeño universitario, a mi compañero de tesis que ha sido parte del proceso para alcanzar la meta que establece la obtención del título de Ingeniero en Sistemas y Computación. A los docentes de la Universidad y al director de carrera por proporcionarme información oportuna y veraz durante todo el desarrollo del proyecto de grado. Luis Arequipa

Agradezco primero a Dios, luego a toda mi familia y a mis amigos, quiero resaltar a mamá que ha sido el más grande regalo que un hijo puede tener, le agradezco por todas sus buenas enseñanzas por siempre estar conmigo en cada momento por ser padre y madre para mi hermano y para mí, le debo tanto a mi madre por lo que soy, ya que ella es el claro ejemplo de una mujer luchadora y trabajadora que saca adelante a su familia, me siento orgulloso de que sea mi mamá y de llevar su apellido con orgullo al igual que el de mi papá, que en paz descanse. ¡Gracias Mamá! Eres lo mejor que me ha pasado en la vida. Bryan Meza

DEDICATORIA Este arduo trabajo lo dedico a Dios, por guiarme, darme fortaleza y permitirme llegar hasta este momento en mi formación profesional. A mis padres Luis Arequipa y Rosa Velásquez por ser el pilar fundamental durante mi vida y el transcurso de toda mi carrera. A mi abuelita Martha Velásquez por brindarme amor, apoyo, soporte cuando la necesitaba. A mi tío Servellón Maya por haberme brindado su cariño y haber formado parte durante mi formación básica. A mis hermanas Anita Arequipa y Andrea Arequipa por haber compartido momentos tensos durante el transcurso de mi carrera y haberme alentado a continuar. A mis profesores por no solo dictar su conocimiento sino también por haber brindado sus consejos y experiencias para lograr cumplir mis objetivos. Luis Arequipa

Dedico este trabajo de titulación a mis tías Margarita Barrera, Viviana Barrera y Alexandra Barrera, además a mis abuelitos Gonzalo Barrera y Carlina Núñez, a todos mis primos, a mi mamá, a mi hermano y a mi papá Carlos Meza que desde el cielo me está mirando. Bryan Meza

vii

RESUMEN El presente documento presenta una posible solución a una problemática reflejada en la Corporación Nacional de Electricidad CNEL-EP, específicamente en el control para el pago y registro de horas extraordinarias, la solución que se busca es automatizar este proceso mediante el desarrollo de un sistema web que sea capaz de acortar el tiempo de realiza esta serie de procesos llevados de una forma manual, además de optar por la tendencia tecnológica que nos brinda el mundo actual. Este documento consta de varios apartados fundamentales que son: El Planteamiento del Problema, El Marco Referencial, Marco Metodológico y Resultados. El primer apartado fundamental es esclarece cual es el tema específico, el alcance que tendrá el desarrollo del sistema y la meta o fin que se busca conseguir con esta posible solución, siguiendo con el Marco Referencial este será el cimiento de la investigación aquí se encontrará el sustento bibliográfico en el cual se basó para realizar este documento, así como también hacer comparativas entre que puede resultar mejor y adaptable a la presente investigación. El Marco Metodológico detalla cada uno de los procesos en orden secuencial, en él se podrá encontrar la selección de la metodología de desarrollo de software, la determinación de la población a la estará dirigida la presente investigación, los instrumentos y herramientas para recolección de datos entre otros más. Por último y no menos importante los resultados. Palabras Clave: Sistema Web, Horas Extraordinarias y Metodología de Software.

viii

ABSTRACT This document presents a possible solution to a problem reproduced in the National Electricity Corporation CNEL-EP, specifically in the control for payment and recording of overtime, the solution required is to automate this process through the development of a web system that is proficient of reducing the time to perform this series of processes operated manually, besides of choosing for the technological trend that the world today offers us. This document is made up of several fundamental sections that are: The Problem Statement, The Reference Framework, The Methodological Framework and The Results. The first fundamental section is to clarify what the specific issue is, the capacity that the development of the system will have and the aim or end that is required to accomplish with this possible solution, following with the Reference Framework this will be the foundation of the research here will be found the bibliographical support on which it was based to make this document, as well as to make comparisons between what can be better and adaptable to the present research. The Methodological Framework details each of the processes in sequential order, it will be possible to find the selection of software development methodology, the determination of the population to which this research will be directed, the instruments and tools for data collection, among others. Last but not least, the results. Keywords: Web System, Overtime and Software Methodology.

ÍNDICE DE CONTENIDOS

1 INTRODUCCIÓN............................................................................................................ 1 2 PLANTEAMIENTO DEL PROBLEMA ......................................................................... 3 2.1 Problema de investigación .................................................................................... 3 2.2 Justificación de la investigación ........................................................................... 3 2.3 Objetivos de investigación.................................................................................... 5 2.3.1 Objetivo General................................................................................................... 5 2.3.2

Objetivos específicos. ........................................................................................... 5

3 MARCO REFERENCIAL ............................................................................................... 6 3.1 Revisión de la literatura o fundamentos teóricos .................................................. 9 3.1.1 Ingeniería de Software. ......................................................................................... 9 3.1.1.1 3.1.1.2 3.1.1.2.1 3.1.1.2.2 3.1.1.2.3 3.1.1.3 3.1.1.3.1 3.1.1.3.1.1 3.1.1.3.1.2 3.1.1.3.1.3 3.1.1.3.1.4 3.1.1.3.1.5 3.1.1.3.1.6 3.1.1.3.1.7 3.1.1.3.1.8 3.1.1.3.1.9 3.1.1.3.1.10 3.1.1.3.1.11 3.1.1.3.1.12 3.1.1.3.2 3.1.1.4 3.1.1.4.1 3.1.2

especificación del software. .................................................................................. 9 metodologías de desarrollo de software tradicionales. ......................................... 9 modelo de la cascada. ........................................................................................... 9 modelo de proceso incremental. ......................................................................... 10 ingeniería de software orientada a la reutilización. ............................................ 10 metodologías de desarrollo de software ágil. ..................................................... 10 modelo scrum. .................................................................................................... 11 roles. ................................................................................................................... 11 cliente.................................................................................................................. 11 product owner. .................................................................................................... 12 scrum master. ...................................................................................................... 12 equipo. ................................................................................................................ 12 coach. .................................................................................................................. 12 proceso. ............................................................................................................... 12 sprint 0. ............................................................................................................... 13 sprints.................................................................................................................. 13 sprint planning. ................................................................................................... 13 daily meeting. ..................................................................................................... 13 review o revisión. ............................................................................................... 13 modelo xp. .......................................................................................................... 13 valores. ................................................................................................................ 14 principios. ........................................................................................................... 14 Base de Datos. .................................................................................................... 14

3.1.2.1 3.1.2.1.1 3.1.2.1.2 3.1.2.1.3 3.1.2.1.4 3.1.2.1.5 3.1.2.1.6 3.1.2.2 3.1.2.2.1 3.1.2.3 3.1.2.3.1 3.1.2.3.2

modelos de base de datos.................................................................................... 15 modelo jerárquico. .............................................................................................. 15 modelo de red. .................................................................................................... 15 modelo relacional. .............................................................................................. 15 modelo entidad-relación. .................................................................................... 15 modelo orientado a objetos. ................................................................................ 16 modelo de datos conceptuales. ........................................................................... 16 sistema de gestión de base de datos. ................................................................... 16 componentes del SGBD...................................................................................... 16 lenguajes de los SGBD. ...................................................................................... 16 diccionario de datos. ........................................................................................... 17 seguridad e integridad de datos. ......................................................................... 17

x 3.1.2.3.3 3.1.2.4 3.1.2.4.1 3.1.2.4.2 3.1.3

mysql. ................................................................................................................. 17 lenguaje SQL de mysql....................................................................................... 17 postgresql. ........................................................................................................... 17 oracle. ................................................................................................................. 18 Aplicaciones Web. .............................................................................................. 18

3.1.3.1 3.1.3.2 3.1.3.2.1 3.1.3.2.2 3.1.3.2.3 3.1.3.3 3.1.3.3.1 3.1.3.3.2 3.1.3.4 3.1.3.4.1 3.1.3.4.2 3.1.3.5 3.1.3.5.1 3.1.3.5.2 3.1.3.5.3 3.1.3.6 3.1.3.6.1 3.1.3.6.2 3.1.3.6.3 3.1.4

componentes de una arquitectura de aplicación web. ......................................... 18 arquitectura en capas. ......................................................................................... 19 arquitectura de dos capas. ................................................................................... 19 arquitectura de n-capas. ...................................................................................... 19 JSP-Model-2 ....................................................................................................... 20 tipos de aplicaciones web. .................................................................................. 21 página web estática. ............................................................................................ 21 página web dinámica. ......................................................................................... 21 editores de código. .............................................................................................. 21 sublime text......................................................................................................... 21 atom. ................................................................................................................... 22 front-end. ............................................................................................................ 22 html. .................................................................................................................... 22 css. ...................................................................................................................... 22 javascript. ............................................................................................................ 23 back-end.............................................................................................................. 23 php. ..................................................................................................................... 23 java...................................................................................................................... 23 asp.net. ................................................................................................................ 23 Responsive Web Design. .................................................................................... 24

3.1.4.1 3.1.4.2 3.1.4.3 3.1.4.3.1 3.1.4.3.2 3.1.4.3.3 3.1.4.4 3.1.4.4.1 3.1.4.4.2 3.1.4.4.3 3.1.4.4.4 3.1.4.5 3.1.4.5.1 3.1.4.5.2 3.1.5

diseño web adaptativo. ....................................................................................... 24 herramienta. ........................................................................................................ 24 frameworks. ........................................................................................................ 25 skeleton. .............................................................................................................. 25 bootstrap. ............................................................................................................ 25 laravel. ................................................................................................................ 26 reglas de oro. ....................................................................................................... 26 viewport. ............................................................................................................. 26 diseño fluido. ...................................................................................................... 26 diseño fijo. .......................................................................................................... 27 diseños adaptativos. ............................................................................................ 27 cms. ..................................................................................................................... 27 wordpress. ........................................................................................................... 28 joomla. ................................................................................................................ 28 Recursos Humanos. ............................................................................................ 28

3.1.5.1 3.1.5.1.1 3.1.5.1.2 3.1.5.1.2.1 3.1.5.1.2.2 3.1.5.1.2.3 3.1.5.1.3 3.1.5.1.4 3.1.5.1.5

administración de recursos humanos. ................................................................. 28 organización........................................................................................................ 29 niveles organizacionales. .................................................................................... 29 nivel institucional. .............................................................................................. 29 nivel intermedio. ................................................................................................. 29 nivel operacional................................................................................................. 29 informática y economía. ..................................................................................... 30 salario en las organizaciones. ............................................................................. 30 prestación social respecto a su exigencia............................................................ 30

xi 3.1.5.1.6 control. ................................................................................................................ 30 3.1.5.2 código de trabajo. ............................................................................................... 30 3.1.5.2.1 reglas. .................................................................................................................. 30 3.1.5.3 rmu. ..................................................................................................................... 32 4 MARCO METODOLÓGICO ........................................................................................ 34 4.1 Diseño/Tipo de Investigación ............................................................................. 34 4.2 Población/Universo ............................................................................................ 35 4.2.1 Población. ........................................................................................................... 35 4.2.2

Muestra. .............................................................................................................. 35

4.3 4.3.1

Técnicas e Instrumentos de Recogida de Datos ................................................. 36 Técnicas. ............................................................................................................. 36

4.3.2

Instrumentos. ...................................................................................................... 36

4.4 4.4.1

Técnicas de Análisis de Datos ............................................................................ 36 Media. ................................................................................................................. 36

4.4.2

Moda. .................................................................................................................. 37

4.5 4.5.1

Metodología de Desarrollo Software .................................................................. 37 Scrum. ................................................................................................................. 39

4.5.1.1 roles en el equipo scrum. .................................................................................... 40 4.5.1.1.1 product owner. .................................................................................................... 40 4.5.1.1.2 scrum master. ...................................................................................................... 40 4.5.1.1.3 proceso scrum. .................................................................................................... 41 4.5.1.1.4 sprint 0. ............................................................................................................... 41 4.5.1.1.5 sprints.................................................................................................................. 41 4.5.1.1.6 retrospectiva. ....................................................................................................... 41 5 RESULTADOS .............................................................................................................. 43 5.1 Análisis de resultados de Entrevista ................................................................... 43 5.2 Análisis de resultados de Encuesta ..................................................................... 45 5.3 Aplicación de la Metodología en el Software .................................................... 57 5.3.1 Planificación. ...................................................................................................... 57 5.3.1.1.1. 5.3.1.1.2. 5.3.1.1.3. 5.3.1.1 5.3.1.2 5.3.1.2.1 5.3.1.2.2 5.3.1.3 5.3.1.4 5.3.1.4.1 5.3.1.4.2 5.3.1.4.3 5.3.1.4.4 5.3.2

requerimientos de usuario. .................................................................................. 57 requerimientos de sistema. ................................................................................. 57 requerimientos de arquitectura. .......................................................................... 58 definición del product backlog. .......................................................................... 59 definición de las herramientas para el desarrollo. .............................................. 60 front-end. ............................................................................................................ 60 back-end.............................................................................................................. 60 número, definición y duración de los sprints. ..................................................... 60 definición de dailys meetings, sprint planning, sprint review y retrospective. .. 61 daily meeting. ..................................................................................................... 61 sprint planning. ................................................................................................... 61 sprint review. ...................................................................................................... 61 retrospectiva. ....................................................................................................... 61 Desarrollo del Sprint 1. ....................................................................................... 62

5.3.2.1 5.3.3

burndown chart sprint 1. ..................................................................................... 63 Desarrollo del Sprint 2. ....................................................................................... 67

5.3.3.1

burndown chart sprint 2. ..................................................................................... 68

xii 5.3.4

Desarrollo del Sprint 3. ....................................................................................... 71

5.3.4.1 5.3.5

burndown chart sprint 3. ..................................................................................... 72 Desarrollo de Pruebas de aceptaciรณn. ................................................................. 74

5.4 5.4.1

Anรกlisis de Impacto ............................................................................................ 74 Impacto Social. ................................................................................................... 75

5.4.2

Impacto Tecnolรณgico. ......................................................................................... 76

5.4.3

Impacto Ambiental. ............................................................................................ 76

5.4.4

Impacto Econรณmico. ........................................................................................... 77

5.4.5

Impacto General. ................................................................................................ 77

6 7 8 9 10

CONCLUSIONES.......................................................................................................... 78 RECOMENDACIONES ................................................................................................ 79 REFERENCIAS ............................................................................................................. 80 GLOSARIO .................................................................................................................... 83 ANEXOS ........................................................................................................................ 84

xiii

ÍNDICE DE TABLAS Tabla 1

Cálculo del pago de horas extraordinarias ............................................................ 7

Tabla 2

Comparativo ente las Metodologías Scrum y XP ............................................... 38

Tabla 3

Comparativo entre Metodologías ....................................................................... 39

Tabla 3

Posesión de un Teléfono Inteligente ................................................................... 45

Tabla 4

Uso fácil de un teléfono inteligente .................................................................... 46

Tabla 5

Smarth-phone enfocados al trabajo .................................................................... 47

Tabla 6

Tipo de Sistema Operativo ................................................................................. 48

Tabla 7

Aplicaciones impartidas por la empresa ............................................................. 49

Tabla 8

Pérdida de tiempo registro de horas extras ......................................................... 50

Tabla 9

Pérdida de tiempo al solicitar información ......................................................... 51

Tabla 10

Sistema Móvil para registro de horas extras ....................................................... 52

Tabla 11

Facilitar el proceso de registro............................................................................ 53

Tabla 12

Sistema Móvil para agilización de procesos ....................................................... 54

Tabla 13

Cumplimiento de Requisitos Horas extras ......................................................... 55

Tabla 14

Conformidad con el proceso actual de registro .................................................. 56

Tabla 15

Roles Scrum ........................................................................................................ 58

Tabla 16

Product Backlog ................................................................................................. 59

Tabla 17

Definición de los Sprints .................................................................................... 60

Tabla 19

BurndownChart del Sprint 1 ............................................................................... 63

Tabla 20

SprintBacklog 2 .................................................................................................. 67

Tabla 22

SprintBacklog 2 .................................................................................................. 71

Tabla 23

Burndown Chart del Sprint 3 .............................................................................. 72

Tabla 24

Niveles de Impacto ............................................................................................. 75

Tabla 25

Impacto Social .................................................................................................... 75

Tabla 26

Impacto Tecnológico .......................................................................................... 76

Tabla 27

Impacto Ambiental ............................................................................................. 76

Tabla 28

Impacto Económico ............................................................................................ 77

Tabla 29

Impacto General ................................................................................................. 77

xiv

ÍNDICE DE FIGURAS Figura 1.

Esquema de contenidos de trabajo de titulación ................................................... 6

Figura 2.

Modelo Cascada ................................................................................................. 10

Figura 3.

Ingeniería de software orientada a reutilización. ................................................ 10

Figura 4.

Roles SCRUM .................................................................................................... 11

Figura 5.

Componentes básicos de una arquitectura de aplicación web. ........................... 18

Figura 6.

Arquitectura de 2 capas para aplicaciones web. ................................................. 19

Figura 7.

Arquitectura de N capas para aplicación web. ................................................... 20

Figura 8.

Arquitectura JSP-Model-2. ................................................................................. 20

Figura 9.

Porcentajes de respuestas de la pregunta 1 ......................................................... 45

Figura 10.

Porcentajes de respuestas de la pregunta 2 ......................................................... 46

Figura 11.

Porcentajes de respuestas de la pregunta 3 ......................................................... 47

Figura 12.

Porcentajes de respuestas de la pregunta 4 ......................................................... 48

Figura 13.

Porcentajes de respuestas de la pregunta 5 ......................................................... 49

Figura 14.

Porcentajes de respuestas de la pregunta 6 ......................................................... 50

Figura 15.

Porcentajes de respuestas de la pregunta 7 ......................................................... 51

Figura 16.

Porcentajes de respuestas de la pregunta 8 ......................................................... 52

Figura 17.

Porcentajes de respuestas de la pregunta 9 ......................................................... 53

Figura 18.

Porcentajes de respuestas de la pregunta 10 ....................................................... 54

Figura 19.

Porcentajes de respuestas de la pregunta 10 ....................................................... 55

Figura 20.

Porcentajes de respuestas de la pregunta 10 ....................................................... 56

Figura 21.

Burndown Chart Sprint 1 .................................................................................... 64

Figura 22.

Modelo Entidad Relación Base de Datos ........................................................... 65

Figura 23.

Figura 24.

Módulos del Sistema .......................................................................................... 66

Figura 25.

Módulo de Conteo de Horas ............................................................................... 66

Figura 26.

Burndown Chart Sprint 2 .................................................................................... 69

Figura 27.

Editar y eliminar ................................................................................................. 70

Figura 28.

Formularios de la empresa ATH´S ..................................................................... 70

Figura 29.

Burndown Chart Sprint 3 .................................................................................... 73

Figura 30.

Generación de Reportes y búsqueda rápida ........................................................ 74

ร NDICE DE ANEXOS Anexo 1. Carta de Aceptaciรณn del Proyecto ............................................................................ 84 Anexo 2. Carta de Impacto ...................................................................................................... 85 Anexo 3. Acta de Entrega ........................................................................................................ 86 Anexo 4. Historias de Usuario ................................................................................................. 87 Anexo 5. Pruebas de Aceptaciรณn ............................................................................................. 94 Anexo 6. Diccionario de datos ................................................................................................. 98 Anexo 7. Presupuesto............................................................................................................. 102

1 INTRODUCCIÓN La tecnología en la actualidad ha vivido una gran evolución en nuestra sociedad, convirtiéndose en una parte fundamental de la vida cotidiana de cada uno de los individuos, es así que esta es empleada en varios campos como: en el entretenimiento, deporte, cultura y en el sector laboral. En este último el buen uso de la tecnología facilita algunas tareas de cualquier empresa o negocio; tales como un sistema de registro de entrada de empleados, como el de un sistema de inventarios. En muchas ocasiones lo que necesita una empresa también son sistemas móviles, que puedan estar disponibles en cualquier lugar que el empleado lo requiera y en estos casos es muy importante aprovechar la tecnología que proveen los Smart-phones (Teléfonos Inteligentes), estos dispositivos tienen muchas funcionalidades importantes que pueden brindar varias ventajas a la empresa, como la automatización de algunas tareas y la disminución de tiempo en el desarrollo de las mismas. Las empresas por lo regular cuentan con muchos procesos para su funcionamiento, debido a que de esta forma se gestionan las actividades diarias, quincenales, mensuales y anuales de forma correcta. Una parte que debe prescindir de un control y proceso es el registro de empleados al momento de su llegada y salida del trabajo, para ello suelen hacer uso de sistemas biométricos que automaticen esa tarea y no volver a décadas atrás en donde debía existir un listado para que cada empleado lo llene a diario, esto significa una pérdida de tiempo y de recursos. Ahora bien, un registro necesario dentro de la Corporación Nacional de Electricidad (CNEL-EP), es el de horas extraordinarias que realiza un trabajador, lo que sucede es que muchas veces el empelado debe trasladarse a sectores en donde por obvias razones no existe ningún sistema biométrico u otro tipo de registro que no sea el de llenar un listado que refleje lo trabajado, es por estos motivos que se necesita que este proceso se facilite y se automatice, de esta manera si existiera un registro que se lo podría realizar desde un computadora o desde el uso de Smat-phones donde la portabilidad se convierte en un gran paso a la adaptación de nuevas tecnologías para la empresa, y de esta forma el registro se haría de una manera mucho más eficaz y rápida aprovechando al máximo el uso de la tecnología que hoy en día está presente en la actividades diarias. Entonces la presente investigación tiene el objetivo de crear un sistema que facilite el control y registro de los empleados que realicen horas extraordinarias en la CNEL-EP

2 Corporación Nacional de Electricidad Empresa Pública de Santo Domingo. De manera que exista un control de parte del personal de Talento Humano para verificar si se han completados las jornadas de horas extraordinarias, y de parte de jefes encargados del personal para comprobar que los empleados asignados han cumplido con su labor. Esta investigación se encontrará dividida en 5 secciones fundamentales, empezando con la presente introducción, el planteamiento del problema donde se reflejarán los antecedentes del tema de investigación, el problema de investigación, la justificación de porque se está realizando este documento y los objetivos que se han planteado. Otra sección muy importante que abarcara este documento es el marco referencial, en este se definirán varios conceptos de relevancia y necesarios para la investigación, dando paso luego a escoger cual o cuales herramientas son las mejores para que sean utilizadas. En el Marco Metodológico que es otro apartado de este documento en donde se tratarán temas como: diseño de la investigación, enfoque de la investigación, tipo de investigación, población, muestra, técnicas e instrumentos de recogida de datos, técnica de análisis de datos, metodología de desarrollo de software y análisis de metodología de desarrollo de software. En la parte final del documento se encuentran los resultados, en donde se evidencia si la investigación ha resuelto el problema que se ha planteado y si es factible la implementación de la aplicación dentro de la empresa en que se está desarrollando esta investigación. Los resultados que se obtendrán serán de gran ayuda debido a que la implementación o no se dará a conocer en este punto.

2 PLANTEAMIENTO DEL PROBLEMA 2.1 Problema de investigación En los últimos años la tecnología se ha convertido en una herramienta diaria de cada persona, puesto que ofrece muchas funcionalidades que pueden facilitar ciertas actividades. Muchas actividades que necesitan ser mejoradas son las de una empresa que busca la optimización de tiempo en estos procesos. Esto es en lo que se basa el tema de investigación. En realizar un sistema móvil para mejorar una de estas actividades como es el registro de pago de horas extraordinarias. Según el análisis realizado se ha formulado la siguiente pregunta general. 

¿Cómo mejorar la gestión del registro de pago de horas extraordinarias en la Corporación Nacional de Electricidad – Empresa Pública de Santo Domingo? Una vez analizado el problema general para facilitar la resolución se ha desglosado en

las siguientes preguntas directrices: 

¿Cuáles son los procesos para el registro de pago de horas extras?



¿Cuáles serán las metodologías de desarrollo de software y recursos más idóneos para crear un sistema eficiente?



¿Cuál será la estrategia más adecuada para la implementación del sistema web?



¿Cuál será la herramienta tecnológica adecuada para el desarrollo del software?

2.2 Justificación de la investigación En la actualidad, la tecnología ha visto un gran crecimiento que se refleja en la aparición de dispositivos móviles inteligentes cada vez más llamativos, con una mayor capacidad de computación y conectividad, llegando incluso a reemplazar a un computador convencional. Hoy en día las empresas están analizando la posibilidad de trasladar ciertas actividades a aplicaciones móviles como una estrategia en de mercado muy satisfactorio para optimizar, mejorar el rendimiento, aumentar la eficiencia laboral.

4 Ecuador, según datos del INEC (Instituto Nacional de Estadística y Censos) en el año 2014, el 45,2% de las empresas investigadas invierten en TIC Tecnologías de la Información y Comunicación (desembolsos realizados por concepto de: compra de los dispositivos físicos, software o aplicaciones informáticas que funcionan sobre estos equipos y similares). Los márgenes entre el mundo físico y el digital se desvanecen, y las apps móviles de consumo están jugando ya un papel muy relevante. Las aplicaciones móviles tendrán un impacto importante en las infraestructuras de información de las empresas, ya que manejar estos datos procedentes de las apps requiere control y tecnologías necesarias para garantizar su inviolabilidad. La investigación ha recaído sobre el objetivo número 11 del Plan Nacional del buen Vivir, debido a que busca la impulsar el uso de la tecnológica en el desarrollo de las actividades que así lo ameriten, el uso de una aplicación móvil en el registro de horas extraordinarias convertirá en una realidad ese objetivo con la cual se busca la conversión de los procesos manuales o físicos en automáticos. Este proyecto nació de una problemática que de acuerdo a la investigación realizada se evidenció la necesidad de minimizar el tiempo que se toma en realizar el proceso de gestión y registro de horas extraordinarias. Todo esto con la finalidad de incentivar el uso de la tecnología en los procesos de la empresa con un sistema amigable al usuario y posea un mejor nivel de funcionamiento. El presente proyecto es factible puesto que cuenta con toda la predisposición tanto de la empresa en brindar toda la información respectiva para el análisis del problema como del equipo de desarrollo en poner en práctica los conocimientos.

2.3 Objetivos de investigación 2.3.1 Objetivo General. Implementar un sistema web para mejorar la gestión del registro de pago de horas extraordinarias en la Corporación Nacional de Electricidad – Empresa Pública Santo Domingo 2017-2018. 2.3.2 Objetivos específicos. 

Determinar los procesos de manejo y control del registro de pago de horas extraordinarias.



Comparar las metodologías de desarrollo de software, herramientas y recursos que se pretenden utilizar para crear un sistema eficiente.



Seleccionar la metodología de desarrollo de software que se adapte a los requerimientos del proyecto.



Desarrollar el sistema web con herramientas tecnológicas actuales.

3 MARCO REFERENCIAL La siguiente figura resume el marco referencial desglosando dos variables importantes dentro del proyecto como son: sistemas web y recursos humanos.

Figura 1. Esquema de contenidos de trabajo de titulación

CNEL EP es la mayor Empresa de distribución y comercialización de energía eléctrica en el Ecuador, se constituyó en sociedad anónima como CNEL S.A. mediante escritura pública de fusión el 15 de diciembre de 2008; y, estuvo integrada por las disueltas empresas eléctricas de distribución: Bolívar S.A., Regional El Oro S.A., Regional Esmeraldas S.A., Regional Guayas-Los Ríos S.A., Manabí S.A., Milagro C.A., Los Ríos S.A., Santo Domingo S.A., Península de Santa Elena S.A. y, Regional Sucumbíos S.A. La CNEL EP Santo Domingo es la encargada de brindar servicio público de distribución y comercialización de energía eléctrica para el bienestar a consumidores de la provincia Tsáchila y sus alrededores incluyendo puntos importantes como San Isidro, Pedernales, El Carmen, etc. Al realizar una visita en la empresa se hicieron varias preguntas como por ejemplo de ¿cómo se lleva a cabo el proceso de registro de horas extraordinarias? A lo que supieron contestar que dentro de la empresa existen tres tipos de estas que son 25%, 50% y 100% de

7 recargo, ademĂĄs de estos tipos de horas extraordinarias se basan en la RemuneraciĂłn Mensual Unificada (RMU), que es una variable para conocer cuĂĄl es el valor monetario que se le debe pagar al empelado que ha realizado esta jornada. Entonces surgiĂł otra pregunta ÂżCĂłmo es el cĂĄlculo de cuanto se le debe pagar a cada empelado?, la respuesta fue que este RMU es diferente para cada empleado dependiendo el cargo que este ejerciendo y que conjuntamente con el nĂşmero de horas realizas mensualmente o quincenalmente se realiza el cĂĄlculo respectivo para el personal. A continuaciĂłn, se detalla las fĂłrmulas que se usan actualmente en CNEL-EP para el cĂĄlculo de pago de horas extraordinarias. Tabla 1 CĂĄlculo del pago de horas extraordinarias Recargo 25% đ?&#x2018;Łđ?&#x2018;&#x17D;đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018;&#x; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D; FĂłrmula đ?&#x2018;&#x2026;đ?&#x2018;&#x20AC;đ?&#x2018;&#x2C6; đ?&#x2018;&#x2026;đ?&#x2018;&#x20AC;đ?&#x2018;&#x2C6; de valor hora =( ) + 50% ( ) FĂłrmula Total a pagar

240 240 đ?&#x2018;&#x2021;đ?&#x2018;&#x153;đ?&#x2018;Ąđ?&#x2018;&#x17D;đ?&#x2018;&#x2122; đ?&#x2018;&#x17D; đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018;&#x201D;đ?&#x2018;&#x17D;đ?&#x2018;&#x; = đ?&#x2018;Łđ?&#x2018;&#x17D;đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018;&#x; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D; đ?&#x2018;Ľ đ??ťđ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018;&#x2014;đ?&#x2018;&#x17D;đ?&#x2018;&#x2018;đ?&#x2018;&#x17D;đ?&#x2018;

50%

100%

đ?&#x2018;Łđ?&#x2018;&#x17D;đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018;&#x; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D; đ?&#x2018;Łđ?&#x2018;&#x17D;đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018;&#x; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D; đ?&#x2018;&#x2026;đ?&#x2018;&#x20AC;đ?&#x2018;&#x2C6; đ?&#x2018;&#x2026;đ?&#x2018;&#x20AC;đ?&#x2018;&#x2C6; đ?&#x2018;&#x2026;đ?&#x2018;&#x20AC;đ?&#x2018;&#x2C6; đ?&#x2018;&#x2026;đ?&#x2018;&#x20AC;đ?&#x2018;&#x2C6; =( ) + 50% ( ) =( ) + 50% ( ) 240 240 240 240 đ?&#x2018;&#x2021;đ?&#x2018;&#x153;đ?&#x2018;Ąđ?&#x2018;&#x17D;đ?&#x2018;&#x2122; đ?&#x2018;&#x17D; đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018;&#x201D;đ?&#x2018;&#x17D;đ?&#x2018;&#x; đ?&#x2018;&#x2021;đ?&#x2018;&#x153;đ?&#x2018;Ąđ?&#x2018;&#x17D;đ?&#x2018;&#x2122; đ?&#x2018;&#x17D; đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018;&#x201D;đ?&#x2018;&#x17D;đ?&#x2018;&#x; = đ?&#x2018;Łđ?&#x2018;&#x17D;đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018;&#x; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D; đ?&#x2018;Ľ đ??ťđ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018;&#x2014;đ?&#x2018;&#x17D;đ?&#x2018;&#x2018;đ?&#x2018;&#x17D;đ?&#x2018; = đ?&#x2018;Łđ?&#x2018;&#x17D;đ?&#x2018;&#x2122;đ?&#x2018;&#x153;đ?&#x2018;&#x; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D; đ?&#x2018;Ľ đ??ťđ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;Ąđ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018;?đ?&#x2018;&#x17D;đ?&#x2018;&#x2014;đ?&#x2018;&#x17D;đ?&#x2018;&#x2018;đ?&#x2018;&#x17D;đ?&#x2018;

Debido al exhaustivo proceso que se realiza un sistema que automatice este procedimiento serĂa un gran ahorro tiempo que puede ser empleado en otras actividades. De esta forma lo que el sistema busca en un principio es del de hacer todo este proceso de forma automĂĄtica. DespuĂŠs de la visita realizada y un anĂĄlisis minucioso de la situaciĂłn en la empresa se identificĂł una inadecuada gestiĂłn en el manejo del registro de pago de horas extraordinarias, por lo que es muy importante mejorar ese aspecto para que sea realizado de la forma mĂĄs eficaz posible. Se ha realizado un proceso de investigaciĂłn con temas de proyecto que tiene similitudes con las dos variables del proyecto. SegĂşn Pinta y Salazar (2013) en su proyecto titulado sistema de control de asistencia de personal del instituto de suelos de grama. Este proyecto abarcĂł con la necesidad de agilizar la gestiĂłn de la informaciĂłn concerniente al registro de asistencia de dicha instituciĂłn el mismo que una vez analizada la problemĂĄtica establecieron segĂşn los autores que la manera mĂĄs Ăłptima de dar soluciĂłn a esta situaciĂłn es mediante el desarrollo de un sistema web.

8 Según Vera (2015) en su trabajo de disertación diseño e implementación de un prototipo de sistema para el registro y control de las horas de pasantías técnicas en los laboratorios de computación. De acuerdo a un análisis previamente realizado según el auto sobre las técnicas de registro y control de pasantías, destacó la necesidad de implementar un prototipo de sistema que aportaría al medio ambiente en la reducción del registro manual en hojas y el tiempo de búsqueda de la información. De acuerdo con Bueno (2017), en su trabajo de tesis sistema de control de horas extras del personal para el proceso de nómina en la gestión de talento humano del gobierno autónomo descentralizado de la provincia de santo domingo de los Tsáchilas, La necesidad de Agilizar la información y el control del proceso de horas extras realizadas del personal del Gobierno Autónomo Descentralizado indujo al autor de dicho proyecto a un análisis minucioso de la mejor forma de agilizar dicho problema utilizando tecnología de la información (TICs), determinando que el desarrollo de una aplicación móvil sería una de las mejores opciones para dar solución a la problemática dada. Según Morales (2013) en su proyecto de análisis, diseño e implementación de un sistema de control y liquidación de personal para una empresa de seguridad y vigilancia. De acuerdo a la problemática de rendimiento, pérdida de tiempo en el proceso de cálculo de liquidación de personal, el presente trabajo de titulación pretende dar solución a dicha problemática dentro de las empresas de vigilancia mediante un sistema de control utilizando herramientas tecnológicas con el fin de asegurar la liquidación correspondiente al personal. Según Oñate (2016) en su proyecto de desarrollo de una aplicación móvil en plataforma android para el control de inventario y facturación de la importadora Juan Pablo. La necesidad de automatizar procesos de control de inventario utilizando la Tecnología de la Información dentro de las empresas. El autor del presente trabajo de titulación ha visto la necesidad de optar por la mejor alternativa de acuerdo a los avances tecnológicos, permitiéndole así llegar a la conclusión de la utilización de dispositivos móviles, por ende, el desarrollo de una aplicación que permita dar solución a dicha problemática dentro de la empresa. Luego de recabar toda esta información necesaria, ninguno de los trabajos investigados se acopla en su totalidad al tema de investigación, por lo que se han extraído

9 diversos y diferentes fragmentos de cada uno de las investigaciones mencionadas en el presente documento.

3.1 Revisión de la literatura o fundamentos teóricos 3.1.1 Ingeniería de Software. La ingeniería de software de acuerdo a Sommerville (2011) es una disciplina de ingeniería que se interesa por todos los aspectos de la producción de software, desde las primeras etapas de la especificación del sistema hasta el mantenimiento del sistema después de que se pone en operación. Es una tecnología con varias capas, según Pressman, (2010) son: Herramientas, Métodos, Proceso y Compromiso de Calidad. Cuyo fundamento es la capa de proceso. 3.1.1.1 especificación del software. Consisten en el proceso de comprender y definir qué servicios se requieren del sistema, así como la identificación de las restricciones sobre la operación y el desarrollo del sistema. Es una etapa particularmente crítica del proceso de software, ya que los errores en esta etapa conducen de manera inevitable a problemas posteriores tanto en diseño como en la implementación del sistema. (Sommerville, 2011). 3.1.1.2 metodologías de desarrollo de software tradicionales. 3.1.1.2.1

modelo de la cascada.

Sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado. (Pressman, 2010). Puede ser muy útil, ayudando a los desarrolladores a diagramar lo que necesitan hacer, Su simplicidad hace que sea fácil explicarlo a los clientes que no estén familiarizados con el desarrollo de software; explicita los productos intermedios que son necesarios a fin de poder comenzar la siguiente etapa de desarrollo. (Lawrence, 2002)

Figura 2. Modelo Cascada Fuente: Tomado de “Ingeniería del software un enfoque práctico” por Pressman, R., 2010, México: McGraw-Hill., p.34.

3.1.1.2.2

modelo de proceso incremental.

El desarrollo incremental se basa en la idea de diseñar una implementación inicial, exponer ésta al comentario del usuario, y luego desarrollarla en sus diversas versiones hasta producir un sistema adecuado (Sommerville, 2011). El modelo de procesos incremental se centra en que en cada incremento se entrega un producto que ya opera. Es útil en particular cuando no se dispone de personal para la implementación completa del proyecto en el plazo establecido por el negocio (Pressman, 2010). 3.1.1.2.3

ingeniería de software orientada a la reutilización.

La ingeniería de software orientada a la reutilización tiene la clara ventaja de reducir la cantidad de software a desarrollar y, por lo tanto, la de disminuir costos y riegos; por lo general, también conduce a entregas más rápidas del software (Sommerville, 2011).

Figura 3. Ingeniería de software orientada a reutilización. Fuente: Tomado de “Ingeniería de software” por Sommerville, I., 2011, México: Pearson Educación de México, p.35.

3.1.1.3 metodologías de desarrollo de software ágil. Los métodos ágiles se apoyan universalmente en el enfoque incremental para la especificación, el desarrollo y la entrega del software. Son más adecuados para el diseño de

11 aplicaciones en que los requerimientos del sistema cambian, por lo general, rápidamente durante el proceso de desarrollo. Tienen la intención de entregar con prontitud el software operativo a los clientes, quienes entonces propondrán requerimientos nuevos y variados para incluir en posteriores iteraciones del sistema. (Sommerville, 2011) 3.1.1.3.1

modelo scrum.

“Se utilizan para guiar actividades de desarrollo dentro de un proceso de análisis que incorpora las siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y entrega” (Sommerville, 2011, p. 69) “Scrum propone un marco de trabajo que puede dar soporte a la innovación, basándose en equipos auto-gestionados. Con Scrum se puede obtener resultados con calidad, en iteraciones cortas (entre una y cuatro semanas) llamadas Sprints” (Álvarez, Heras del Dedo y Lasa, 2012, p. 39). 3.1.1.3.1.1 roles. Los roles engloban a todos los que intervienen en el “Equipo Scrum” como el Product Owner, al Scrum Master y al equipo de trabajo (Álvarez et al., 2012).

Figura 4. Roles SCRUM Fuente: Tomado de “Manual imprescindible de Métodos ágiles y Scrum” por Álvarez García, A., Heras del Dedo, R., & Gómez, C., 2012, Madrid, España: Anaya Multimedia, p. 64.

3.1.1.3.1.2 cliente. Conocido como grupo de personas interesadas en el trabajo que pueden o no formar parte de la empresa, toma un papel muy importante puesto que aporta en dos partes

12 fundamentales como el de proporcionar requisitos o lo que quiere construir

y validar

resultados cuidadosamente para brindar alguna corrección para su posterior revisión. (Álvarez et al., 2012). 3.1.1.3.1.3 product owner. Este personaje juega un papel fundamental ya que viene a ser el representante del cliente al cual siempre estará disponible para el equipo, encargado de transmitir lo que desea el cliente como los requisitos, sus reacciones y aceptar o rechazar las entregas del equipo por medio de revisiones de Sprints. Así como también es responsable de la rentabilidad del negocio, es decir el éxito o fracaso del producto (Álvarez et al., 2012). 3.1.1.3.1.4 scrum master. Persona que trabaja muy cerca del equipo, en conjunto con el product owner, ayudando en evaluación de resultados, velocidad del equipo de desarrollo, fomentando la productividad al equipo y sobretodo tiene como objetivo hacerse prescindible y permitir que el equipo sea capaz de funcionar sin su figura (Álvarez et al., 2012). 3.1.1.3.1.5 equipo. Juega un rol muy específico puesto que sin la presencia del equipo Scrum sería imposible llevar a cabo el proyecto. Los mismos deben tener una actitud elevada de compromiso y aptitudes para desarrollar el proyecto. Cabe recalcar que es imprescindible que el equipo deba entrar en mejora continua en lo que se refiere a conocimientos y habilidades, como en las mejoras prácticas en su trabajo (Álvarez et al., 2012). 3.1.1.3.1.6 coach. Es una figura que puede o no estar presente en el proyecto, ésta persona trabaja de forma similar a un mentor de un equipo cuyas funciones son ayudar a aplicar las técnicas Scrum de forma correcta y motivar a todo el equipo a lograr sus objetivos (Álvarez et al., 2012). 3.1.1.3.1.7 proceso. Los procesos Scrum se dividen en dos etapas como son: la preparación (Sprint 0) y las sucesivas iteraciones (Sprints), agrupadas en entregas (Álvarez et al., 2012).

13 3.1.1.3.1.8 sprint 0. Es una etapa de duración variable pero no indefinida en la cual se debe recalcar dos objetivos importantes como son: las condiciones y el contenido de trabajo, en donde la condición engloba el alcance del proyecto como recursos financieros, humanos para desarrollarlo y el marco temporal de entrega de resultados. Cabe recalcar que al final de este sprint se determinará si el proyecto es viable es decir cuenta con medios y apoyo necesario (Álvarez et al., 2012). 3.1.1.3.1.9 sprints. Esta etapa tiene como objetivo garantizar el compromiso entre la capacidad del equipo de trabajo y las necesidades expresadas por Product Owner y consta de tres etapas Sprint Planning, Daily Meetings y Review (Álvarez et al., 2012). 3.1.1.3.1.10

sprint planning.

La planificación del Sprint trabaja en función del tiempo en el que se va a planificar lo que se va a realizar. Se toman como base las necesidades del cliente para determinar cuáles van a ser las funcionalidades para el siguiente Sprint (Álvarez et al., 2012). 3.1.1.3.1.11

daily meeting.

En este tipo de reuniones breves que se realiza diariamente buscando que cada miembro del equipo participe detallando la actividad que ha realizado, seleccionando la próxima tarea que realizará y el posible problema o impedimento que tuvo con dicha tarea (Álvarez et al., 2012). 3.1.1.3.1.12

review o revisión.

Se trata de un tipo de reunión en donde intervienen todos los miembros del proyecto para dar opiniones sobre los resultados obtenidos y se han cumplido o los objetivos destacados al inicio del proyecto (Álvarez et al., 2012). 3.1.1.3.2

modelo xp.

Sommerville (2011), define al modelo XP como un método quizás el más conocido, el cual se procura potenciar las relaciones interpersonales como una clave para el éxito del

14 proyecto, además define como un modelo en casos de proyectos con requisitos imprecisos y cambiantes en donde existan riesgos. 3.1.1.4 valores. Se definen 5 valore principales del desarrollo XP entre los que están la comunicación, simplicidad, feedback, coraje y respeto (Álvarez et al., 2012): 

Comunicación. Es una de las bases fundamentales para evitar problemas o malos entendidos entre los miembros del equipo y el cliente. Además, recalca que hay muchas formas de establecer una buena comunicación como por ejemplo al utilizar medios escritos bien redactados con un código simple.



Simplicidad. Trata que las cosas se deben hacer de la forma más simple posible sin comprometer la calidad.



Feedback. Está relacionado con los dos objetivos anteriores y es necesario para conocer cuan cerca está el proyecto de lo que se quiere alcanzar



Coraje. Este valor representa valentía al momento de aplicar los valores antes mencionados al trabajo puesto que el desconocimiento de método puede generar cierta duda que ponga en consideración la aplicación del método.



Respeto. Es un valor que se encuentra presente en todos los valores anteriores ya que ninguno de ellos puede funcionar sin él.

3.1.1.4.1

principios.

(Álvarez et al., 2012), menciona q los principios principalmente aplicables en todo proyecto de desarrollo de software son: humanidad, economía, beneficio mutuo, autosemejanza, mejora continua, diversidad, etc. 3.1.2 Base de Datos. Reinosa, Maldonado, Muñoz, Damiano y Abrutsky (2014) define a la base de datos como un conjunto de estructuras cuya finalidad es evitar la redundancia, es decir la repetición en el momento de definir los almacenamientos de datos y almacenar toda la información en un medio físico como un disco duro.

15 3.1.2.1 modelos de base de datos. “Un modelo de datos brinda distintos conceptos y permite definir las reglas y las estructuras para el almacenamiento de datos para, después, manipularlos” (Reinosa et al., 2014, p. 17). 3.1.2.1.1

modelo jerárquico.

Según (Piñeiro, 2013) existe una jerarquía para la representación lógica de los datos tipo árbol familiar en los que el un padre puede tener varios hijos, pero cada hijo pertenece a un padre. Este modelo fue desarrollado para proyectos de gran escala, puesto que trabaja con grandes cantidades de datos (Coronel, 2011). 3.1.2.1.2

modelo de red.

“El modelo de datos de red se basa en la utilización de una estructura no lineal en la que cada registro hijo puede tener más de un nodo padre” (Piñeiro, 2013, p.14). (Coronel, 2011) menciona que este tipo de modelo fue más efectivo para mejorar la operación de una base de datos e imponer un estándar, además de permitir que un registro tenga más de un padre. 3.1.2.1.3

modelo relacional.

En este tipo de modelo se utilizan tablas para una mejora apreciación de la lógica de los datos como las relaciones entre ellos (Piñeiro, 2013). El modelo relacional es el modelo más empleado en la actualidad, entre algunos de los sistemas gestores de base de datos que utilizan el modelo relacional son Oracle, SQL Server, MySQL, etc. 3.1.2.1.4

modelo entidad-relación.

Este modelo por lo general representa en un diagrama el resultado del análisis del problema, que utiliza representaciones gráficas para modelar los componentes de datos.

16 “Los elementos básicos del modelo entidad-relación propuestos por Chen son las entidades, las relaciones y los atributos” (Piñeiro, 2013, p.11). 3.1.2.1.5

modelo orientado a objetos.

Este modelo de acuerdo con (Piñeiro, 2013), parte por la integración de varios métodos de análisis y diseño orientado a objetos, dando lugar a la aparición de un lenguaje UML, el cual establece normas que se deben seguir cuando se emplea el modelo orientado a objetos. 3.1.2.1.6

modelo de datos conceptuales.

“En estos modelos se describen los datos del universo del discurso tal y como lo captamos en el mundo real, esto es, alejados de su implementación en el ordenador en un SGBD concreto” (Piñeiro, 2013, p.11). 3.1.2.2 sistema de gestión de base de datos. Es un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. En concreto se define como una colección de datos relacionados entre sí y un conjunto de programas que accedan y gestionen esos datos (Valderrey, 2013, p.31). Valderrey (2013) define que el propósito general de los SGBD es manejar de manera ágil, sencilla y ordenada los datos, así como también define que son un conjunto de programas que tienen la potestad de acceder y gestionar esos datos. 3.1.2.2.1

componentes del SGBD.

3.1.2.3 lenguajes de los SGBD. Los sistemas gestores de base de datos ofrecen lenguajes y e interfaces de acuerdo a cada tipo de usuario, entre los cuales encontramos (Valderrey, 2013): 

Lenguaje de definición de datos (DDL): Permite a los diseñadores y administradores de la base de datos definir la estructura de la base de datos.



Lenguaje de manipulación de datos (DML): Se utiliza para leer y actualizar los datos de la base de datos.

17 

Lenguajes declarativos: Permiten especificar los datos a obtener en consultas, o los datos a modificar, mediante sentencias sencillas.



Lenguajes 4GL: Permiten al usuario desarrollar aplicaciones de forma fácil y rápida, generalmente están presentes el SGBD comerciales.

3.1.2.3.1

diccionario de datos.

Es el lugar donde se deposita información acerca de todos los datos que forman la base de datos. Es una guía en la que se describe la base de datos y los objetos que la forman. Contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización (Valderrey, 2013). 3.1.2.3.2

seguridad e integridad de datos.

Los sistemas gestores de base de datos deben garantizar la protección contra accesos no autorizados ofreciendo mecanismos para implantar restricciones de integridad, copias de seguridad y restauración (Valderrey, 2013). 3.1.2.3.3

mysql.

“MySQL es un sistema gestor de base de datos relacional cliente-servidor de coste mínimo que incluye un servidor SQL, programas cliente para acceder al servidor, herramientas administrativas y una interfaz de programación para escribir programas” (Pérez, 2015, p.9). MySQL es la base de datos de código abierto más popular en el mundo convirtiéndose en una de las principales opciones para aplicaciones basadas en web. (MySQL, 2017) 3.1.2.4 lenguaje SQL de mysql. SQL es un lenguaje estructurado de MySQL cuyo principal objetivo es controlar e interactuar con el sistema de gestión de base de datos, además de brindar un lenguaje muy potente y fácil de aprender es útil también para el desarrollo web (Pérez, 2015). 3.1.2.4.1

postgresql.

“PostgreSQL es un poderoso sistema de base de datos relacional de objetos código abierto. Tiene más de 15 años de desarrollo activo y una arquitectura comprobada que le ha

18 valido una sólida reputación de fiabilidad, integridad de datos y corrección” (PostgreSQL, 2017). Este tipo de software ha sido creado y diseñado para tener requisitos de ajuste y mantenimiento mucho más bajos que las bases de datos propietarios líderes, y aun así conservando todas las funciones, la estabilidad y el rendimiento” (PostgreSQL, 2017) Se ejecuta en todos los principales sistemas operativos, incluidos Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, macOS, Solaris, Tru64) y Windows” (PostgreSQL, 2017) 3.1.2.4.2

oracle.

Oracle es básicamente una herramienta cliente/servidor para la gestión de base de datos, que además de ir actualizando cada vez sus versiones es una de las empresas que garantiza el funcionamiento de sus bases de datos, compensando económicamente si hubiere fallo de algún servidor. Ha sido diseñada para que las organizaciones puedan controlar y gestionar grandes volúmenes de contenido no estructurado en un único repositorio para disminuir costes y riesgos asociados a perdidas (Oracle, 2017) Oracle es un sistema gestor de base de datos que proporciona grandes beneficios en comparación con otros sistemas gestores de bases de datos, entre las que se encuentran seguridad, disponibilidad, estabilidad, controles de acceso, robustez, brindando a los usuarios un producto confiable y seguro. 3.1.3 Aplicaciones Web. 3.1.3.1

componentes de una arquitectura de aplicación web.

Figura 5. Componentes básicos de una arquitectura de aplicación web. Fuente: Tomado de “Web engineering” por Kappel, G., Pröll, B., Reich, S., & Retschitzegger, W., 2011, Heidelberg: Dpunkt-Verlag, p. 72.

19 La comunicación entre estos componentes generalmente se basa en el principio solicitud-respuesta, es decir, un componente envía una solicitud a otro componente y la respuesta a dicha solicitud se envía por el mismo canal de comunicación (Kappel, Pröll, Reich y Retschitzegger, 2011). 3.1.3.2 arquitectura en capas. 3.1.3.2.1

arquitectura de dos capas.

Arquitectura también conocida como Cliente-Servidor, la cual funciona cuando un usuario en su estación de trabajo envía solicitudes a un servidor para ejecutar operaciones complejas, es adecuada particularmente para aplicaciones web simples más no para aplicaciones más exigentes (Kappel et al., 2011).

Figura 6. Arquitectura de 2 capas para aplicaciones web (De acuerdo a Romberg 2001, p.40). Fuente: Tomado de “Web engineering” por Kappel, G., Pröll, B., Reich, S., & Retschitzegger, W., 2011, Heidelberg: Dpunkt-Verlag, p. 72.

3.1.3.2.2

arquitectura de n-capas.

La Arquitectura de N-capas nos permite organizar una aplicación web en un número arbitrario de capas. Por lo general consta de tres capas (Kappel et al., 2011): 

Capa de datos. Proporciona acceso a los datos de la aplicación.



Capa empresarial. Aloja los programas que se ejecutan en un servidor de aplicaciones.



Capa de presentación. Referente a interacción entre usuario y software, esta capa muestra la información al usuario.

Figura 7. Arquitectura de N capas para aplicación web. Fuente: Tomado de “Web engineering” por Kappel, G., Pröll, B., Reich, S., & Retschitzegger, W., 2011, Heidelberg: Dpunkt-Verlag, p. 72.

3.1.3.2.3

JSP-Model-2

JSP-Model-2 es un modelo utilizado en diseño de aplicaciones web, el cual se asocia al modelo vista-controlador (MVC) e integra el uso de servlets y páginas JSP en donde JSP se utiliza para la capa de presentación y los servlets para las tareas de procesamiento. Esta modelo en si accede a los sistemas backend como a una base de datos. (Kappel et al., 2011).

Figura 8. Arquitectura JSP-Model-2. Fuente: Kappel, G., Pröll, B., Reich, S., & Retschitzegger, W. (2011). Web engineering. Heidelberg: Dpunkt-Verlag. (p. 72).

21 3.1.3.3 tipos de aplicaciones web. 3.1.3.3.1

página web estática.

Las páginas web estáticas limitan la interacción entre el usuario y la página, es decir muestra la información de forma permanente en donde el usuario tiene la limitante de obtener dicha información sin una interacción con la página web visitada. Éste tipo de página web está formada principalmente por enlaces a otros sitios web. (Zofio, 2013). 3.1.3.3.2

página web dinámica.

Páginas web dinámicas otorgan mayor interactividad entre el navegante y la aplicación en donde el contenido suele generarse en el momento de visualizarse por ende el contenido puede variar como en consultas de correo, formularios. El contenido en este tipo de páginas es frecuentemente actualizado lo cual favorece enormemente la eficacia de la página para atraer usuarios. (Zofio, 2013). 3.1.3.4 editores de código. 3.1.3.4.1

sublime text.

Es un editor de texto con todas las funciones ideales para editar archivos de texto locales. Tiene muchas funciones incorporadas para ayudar a editar código, como resaltado de sintaxis, sangría automática, reconocimiento de tipo de archivo, una práctica barra lateral de archivo / carpeta para editar fácilmente varios archivos dentro de un directorio, macros para automatizar tareas repetitivas y pestañas y una opción de ventana dividida para ver y editar múltiples archivos al mismo tiempo (Haughee, 2013). Entre muchas de las ventajas que en la actualidad nos ofrecen los diferentes editores de código, Sublime Text es uno de los que nos brinda muchas funcionalidades que hacen de él un editor potente, entre las principales características que nos brinda es su reducido tamaño del instalador, arranque inmediato y su principal característica con una amplia gama de funcionalidades a través de plugin que permiten al programador agilizar la tarea de desarrollo de software.

22 3.1.3.4.2

atom.

Atom es un editor de texto que es moderno, accesible, pero que se puede descifrar hasta el núcleo, una herramienta que puedes personalizar para hacer cualquier cosa, pero también utilizarla de manera productiva sin tener que tocar un archivo de configuración. (Atom, 2017) 3.1.3.5 front-end. 3.1.3.5.1

html.

“El Hypertext Markup Language (HTML) es un lenguaje de programación. A diferencia de otros lenguajes, no está compuesto por instrucciones, sino por un conjunto de etiquetas que organizan y declaran el propósito de cada contenido del documento” (Gauchat, 2014, p.25). “HTML es parte esencial de la Web y ha logrado cambiar y madurar el ritmo de internet en general” (Herrera, 2013, p.3). De acuerdo con Gómez (2013), HTML es un lenguaje de hipertexto ya que nos permite presentar información estructurada, es decir codificada mediante marcas y etiquetas. HTML5 (nueva versión de HTML) que proporciona una manera de realizar código más fácil para escribir. Incorporando grandes funcionalidades

como estructura, estilo y

funcionalidad cubriendo así la demanda de funcionalidades por parte del programador (Gauchat, 2014, p.25). 3.1.3.5.2

css.

CSS en un lenguaje cooperativo que trabaja en conjunto con HTML para dar una mejor apariencia a la página web al aplicar diferentes estilos visuales a los elementos del documento (color, tamaño, fondos, bordes, etc.). Define básicamente como se mostrarán en pantalla la sintaxis escrita en HTML (Gauchat, 2014). De acuerdo con Oros (2013), define que la idea que se encuentra detrás de los CSS es separar la manera de presentar el documento con la estructura del mismo.

23 3.1.3.5.3

javascript.

JavaScript es un lenguaje de programación creado con el objetivo de integrarse con HTML en el que podemos desarrollar programas que se ejecuten directamente con el navegador, el mismo que nos permitirá crear páginas que tengan más interactividad con el cliente. (Oros, 2013). Javascript es un lenguaje interpretado utilizado para múltiples propósitos que hoy en día no se concibe el desarrollo web sin el uso de ésta tecnología. (Gómez, 2013). 3.1.3.6 back-end. 3.1.3.6.1

php.

PHP posee un lenguaje interpretado del lado del servidor muy sencillo de aprender que se caracteriza por su potencia, versatilidad, robustez, modularidad y multiplataforma (Cobo, Gómez, Pérez y Rocha, 2008). PHP es un proyecto de código libre que se ha convertido, de facto, en la opción para el desarrollo de aplicaciones Web orientado a base de datos puesto que ha sido su soporte para reconocidas bases de datos como Oracle, MySQL, PostgreSQL y Miscrosoft SQL Server. (Vaswani, 2010) 3.1.3.6.2

java.

Java es el lenguaje de programación de computadoras orientado a objetos más utilizado del mundo, que tiene un objetivo clave el cual es poder escribir programas que se ejecuten en una amplia gama de sistemas computacionales orientándose en la frase “escribir una vez, ejecutar en cualquier parte”. (Deitel & Deitel, 2012). Éste lenguaje de programación se ha convertido en un pilar fundamental el mundo de Sistemas ya que se necesita tener la capacidad de programar en Java para ser programadores profesionales. (Rubiales, 2013) 3.1.3.6.3

asp.net.

ASP.NET es un modelo de desarrollo Web unificado que incluye los servicios necesarios para crear aplicaciones Web empresariales con el código mínimo que puede ser escrito en Visual Basic, C#, entre otros, y debe ser compatible con Common Language Runtime (Microsoft, 2016). ASP.NET posee grandes ventajas en lo referente al rendimiento,

24 simplicidad, facilidad de uso y seguridad que hacen de este un marco de trabajo eficaz en aplicaciones web. (Vanegas, 2012). 3.1.4 Responsive Web Design. 3.1.4.1 diseño web adaptativo. La adaptabilidad es la habilidad que tiene una persona u objeto de adaptarse, acomodarse ajustarse a otro espacio. En la actualidad el diseño web adaptativo es muy importante dentro del diseño de una página o sistema web, debido a que este de ajustarse a al tamaño y resolución de cualquier dispositivo en la actualidad como son: Smart-phones, tablets y/o computadoras, entonces lo que busca un sistema es adecuarse a cada uno de estos, sin sacrificar legibilidad, amigabilidad y funcionamiento con el usuario final. En la actualidad, la técnica es bien conocida y goza de aceptación. Pero sigue siendo novedosa, todavía es joven, y está sujeta a debate en muchos de sus aspectos. En el mundo anglosajón, ya hay una amplia bibliografía y el término con el que nació se ha consolidado como Responsive Web Design (Bonilla, 2014). Con la independencia de un navegador u otro, el diseño web en la actualidad tiene la adecuación entre contenidos y dispositivos. Este es el fundamento del diseño web adaptativo. Se trata de crear contenidos con capacidad de responder al medio en donde se va mostar. (Bonilla, 2014). 3.1.4.2 herramienta. Ahora bien, existen varias herramientas que ayudan de alguna manera al diseño responsivo dentro de un sistema web o sitio web, una herramienta que resulta muy útil es CAN I USE para conocer cuáles son las características que soportan los diferentes navegadores con cada una de las versiones de HTML y CSS, es decir esta herramienta contiene información sobre la compatibilidad de los navegadores. Según Bonilla (2014) existe otra herramienta muy interesante dentro de los sitios web es StatCounter, esta herramienta se encarga de la recolección de datos actualizados sobre el uso que hacen los usuarios en los navegadores. Esta herramienta permite conocer el porcentaje de personas que utilizan un navegador, además de poder filtrar por zonas

25 geográficas y periodos de tiempo concretos, esto será de gran ayuda debido a que nos permitirá tomar decisiones correctas sobre qué hacer en situaciones concretas. Una herramienta bastante usada en la actualidad en muchos proyectos para aumentar el control sobre el resultado es Modernizr. Modernizr es una librería de JavaScript que detecta HTML5 y CSS3 en el navegador del usuario. Si vamos a utilizar HTML5 o CSS3 en el proyecto, esta herramienta indica que elementos o funcionalidades de estos lenguajes están disponibles en el navegador usado. Saber las capacidades que soporta el navegador, nos da la posibilidad de crear alternativas para esos casis en los que la funcionalidad que hemos previsto usar esté soportada por alguno de los navegadores (Bonilla, 2014). 3.1.4.3 frameworks. Un Framework es un conjunto estructurado y completo de archivos HTML, CSS, JS, etc., que proporcionan un entorno de trabajo preparado para ser utilizado como base en un proyecto. En el caso que nos ocupa una característica añadida es que, los Frameworks son adaptativos. Para ello disponen de un sistema de retícula que fácilmente permite decidir la estructura que se quiere aplicar a cada proyecto. Sin ninguna duda, utilizar alguna de estas soluciones existentes supone una ayuda estimable que va a simplificar el proceso de creación el sitio pues ponen a nuestra disposición, listo para ser usado, la base para el proyecto con muchos aspectos ya desarrollados y plenamente funcionales. De este modo, el diseñador queda liberado de tareas repetitivas y puede centrarse en lo propio y específico de cada proyecto (Bonilla, 2014). 3.1.4.3.1

skeleton.

Skeleton es un framework bastante completo y sencillo de utilizar. Skeleton es un framework adaptativo que trabaja con 3 media queries, siendo los pintos de cabio los 480px, 768px y 960px. (Bonilla, 2014, p.174). 3.1.4.3.2

bootstrap.

Bootstrap es un framework de los denominados front-end que goza de una gran popularidad. Desarrollado y liberado por Twitter, da soporte a un gran número de

26 funcionalidades. Además de una estructura en columnas incluye, entre otros, desplegables, botones, formularios, tablas, barras de progreso y carruseles de imágenes (Bonilla, 2014) 3.1.4.3.3

laravel.

Laravel es uno de los frameworks de código abierto más fáciles de asimilar para PHP. Es simple, muy potente y tiene una interfaz elegante y divertida de usar. Fue creado en 2011 y tiene una gran influencia de frameworks como Ruby on Rails, Sinatra y ASP.NET MVC (García, 2015). Laravel es un framework de desarrollo que utiliza una arquitectura MVC el cual consiste en dividir la aplicación en tres módulos: el modelo, la vista y el controlador, buscando así facilitar la tarea de desarrollo y mantenimiento de aplicaciones. Además de proporcionar beneficios al desarrollador como abundante documentación, manejador de dependencias “Composer”, herramienta de línea de comando “Artisan”, motor de plantillas “Blade” para facilitar las tareas al programador. 3.1.4.4 reglas de oro. 3.1.4.4.1

viewport.

Viewport es un atributo de la etiqueta meta que hace referencia al área visible de la pantalla, el área en el que se muestra el contenido web. Normalmente, las dimensiones del viewport son algo más pequeñas que las dimensiones reales de la pantalla del dispositivo. El viewport permite configurar como va a interpretar el navegador las dimensiones de la página correspondiente. Actúa sobre las dimensiones y la posibilidad de escalar la imagen (Bonilla, 2014). 3.1.4.4.2

diseño fluido.

Los diseños fluidos no son una novedad, se utilizan desde hace tiempo. Lo característico de estos diseños es que utilizan unidades porcentuales para determinar la anchura de los elementos. Esto hace que los contenidos se ajusten a la ventana, aumentando o disminuyendo su tamaño que ya no es fijo. El contenido ocupa el espacio disponible. En la actualidad los modelos fluidos dan un buen resultado si se lo combina con otros modelos de diseño (Bonilla, 2014).

27 3.1.4.4.3

diseño fijo.

El diseño web fijo ha sido el más utilizado hasta los tiempos actuales. Los diseñadores apuntaban a la resolución de pantalla más utilizada y fijaban unas dimensiones determinadas para el ancho de los documentos. Primero fue 800x600, luego 1024x768. 3.1.4.4.4

diseños adaptativos.

Esta técnica, aunque específica para dispositivos móviles, está realizada dentro del contexto "One Web", y que por lo tanto engloba no sólo la experiencia de navegación en dispositivos móviles sino también en dispositivos de mayor resolución de pantalla como tabletas, netbooks, portátiles o dispositivos de sobremesa, etc. El concepto de "One Web" hace referencia a la idea de construir una Web para todos (Web for All) y accesible desde cualquier tipo de dispositivo (Web on Everything). El ahorro de tiempo para desarrollar un sitio web adaptativo es considerable, sobre todo si el desarrollo se realiza en un CMS, pues con una sola versión en HTML y CSS se cubren todas las resoluciones de pantalla que se puedan necesitar optimizadas para cualquier tipo de dispositivos. De esta forma se reducen los costes de creación y mantenimiento, pues se evita tener que desarrollar aplicaciones expresas para versiones móviles, por ejemplo, una para iPhone, otra para Android, etc. (Rubio, 2018). 3.1.4.5 cms. Un CMS, siglas del término Inglés Content Management System, traducido como Sistema de gestión de contenidos, es una aplicación desarrollada para que cualquier usuario pueda administrar y gestionar contenidos de una web con facilidad y sin conocimientos de programación. Originalmente los CMS fueron concebidos como una solución adecuad para proyectos que conjugaban la necesidad de organizar y, a la vez, gestionar una gran cantidad de información (Bonilla, 2014). Además, es importante mencionar que en la actualidad los CMS son adaptativos, Wordpress y Joomlla son un claro ejemplo de ello.

28 3.1.4.5.1

wordpress.

Desde su nacimiento. Su popularidad no ha dejado de crecer y es, en la actualidad, el CMS más utilizado. Con una cuota de mercado cercana al 70%, supera con mucho, alas otras opciones existentes. (Bonilla, 2014, p.190). Inicialmente fue creado para editar blogs, pero a la vez que ganaba popularidad fue creciendo, dos aspectos que promovieron el uso de este CMS fue su instalación rápida en 5 minutos y el fácil uso que maneja, esto ha convencido a desarrolladores y diseñadores. 3.1.4.5.2

joomla.

Joomla nació en 2005 como una evolucaiòn de Mambo, del que se separò. Al igual que wordpress, tiene le gran atractivo de ser Open Source. Utiliza como base de datos MySQL, donde se guarda toda la información. Los scripts de PHP son los que van a interactuar con esos datos mediante consultas y convierten sus respuestas en datos servidos a los usuarios en forma de contenido web. Es multiplataforma (Bonilla, 2014). 3.1.5 Recursos Humanos. 3.1.5.1 administración de recursos humanos. El talento humano dentro de la empresa es fundamental dentro de cualquier organización y según Chiavenato este talento humano se convierte en un capital para la empresa. Esto es en donde la competencia de una persona se convierte en la capacidad de desenvolverse en cualquier situación para generar activos para la empresa. Muchas veces no es necesario tener un personal amplio para generar productividad, más bien que los empleados sientan un compromiso con la empresa, para ello es necesario que estén rodeados de un clima que impulse a las personas y se use de manera correcta los talentos existentes en la empresa. De este modo la utilización plena del capital humano llevará a la empresa a una mayor productividad (Chiavenato, 2011). En una organización existe una relación esencial entre las personas y la empresa, debido a que las personas que trabajan allí dependen de la organización para vivir, y a su vez la organización está constituida de personas por lo que sin ellas no existiría. Es por eso que sin esta interacción continua no habrá una correcta administración de los recursos humanos (Chiavenato, 2011).

29 Antiguamente se consideraba al talento humano de la empresa como un estándar, es decir los recursos humanos trataban a las personas como si estas fueran iguales. Actualmente las diferencias individuales se toman cada vez en cuenta por parte de la empresa, y la razón de esto es sencilla: cuanto mayor es la diferencia entre personas, tanto mayor su potencial de creatividad e innovación (Chiavenato, 2011). 3.1.5.1.1

organización.

Las organizaciones según Chiavenato (2011), está conformado por un grupo de personas las cuales trabajan con valores para alcanzar un bien en común y satisfacer todas las necesidades personales, siguiendo una planificación estratégica analizada con anterioridad. Cabe recalcar que el crecimiento de las mismas recae en actividades de evolución como el crecimiento tanto en recursos físicos como recursos humanos. 3.1.5.1.2

niveles organizacionales.

3.1.5.1.2.1 nivel institucional. De acuerdo con Chiavenato (2011), el nivel institucional es uno de los más altos e importantes, ya que están conformados por altos directivos de una empresa los cuales buscan el bienestar de la misma mediante la formulación de planes estratégicos y administrativos para de esa manera lograr alcanzas sus objetivos. 3.1.5.1.2.2 nivel intermedio. Nivel intermedio o también conocido como nivel táctico está conformado por departamentos en específico, es el encargado de actuar como mediador entre el nivel institucional y el nivel operacional ya que una vez obtenido los resultados de nivel institucional procede a dirigirlos a nivel operacional para su posterior ejecución (Chiavenato, 2011). 3.1.5.1.2.3 nivel operacional. Nivel operacional es uno de los niveles que se encarga del trabajo fuerte y sin lugar a dudas es indispensable ya que también se lo conoce como núcleo técnico. Comprende una secuencia de actividades coordinadas en conjunto con la tecnología, que habrán de realizarse para alcanzar los objetivos (Chiavenato, 2011).

30 3.1.5.1.3

informática y economía.

La informática es un ámbito que juega un papel muy importante dentro del mundo empresarial ya que mediante la implementación de tecnología de la información (TIC) permite cumplir objetivos estratégicos y el desarrollo de la misma con la finalidad de aumentar los recursos informáticos y facilitar la creación y el tratamiento de la información en la empresa (Mendoza, 2012). 3.1.5.1.4

salario en las organizaciones.

De acuerdo con Chiavenato (2011), el salario en las organizaciones representa factores que pueden beneficiar al desarrollo o afectar en el rendimiento a los trabajadores, los cuales se determinan mediante evaluación de puestos en los que intervienen criterios y técnicas para realizar análisis y categorización salarial logrando así un equilibrio interno. 3.1.5.1.5

prestación social respecto a su exigencia.

Según Chiavenato (2011), las prestaciones sociales respecto a su exigencia se dividen en dos tipos de prestaciones: prestaciones legales y prestaciones adicionales. Las prestaciones legales son beneficios obtenidos por el trabajador y otorgados por el empleador entre las que destaca horas extras y las prestaciones adicionales que son otorgadas voluntariamente sin ley que exija dicha prestación. 3.1.5.1.6

control.

Control es uno de los factores indispensables en una empresa, que impactan de gran manera en el desarrollo de la misma permitiendo alcanzar objetivos definidos, ya que se encargan de asegurar de que el proceso siga el camino previsto. Aplicando el control a nivel operativo tiene como función evaluar alguna anomalía para corregirla posteriormente (Chiavenato, 2011). 3.1.5.2 código de trabajo. 3.1.5.2.1

reglas.

Base Legal Del contrato individual de trabajo (Ministerio de Trabajo, 2013)

31 Capítulo 5 De la duración máxima de la jornada de trabajo, de los descansos obligatorios y de las vacaciones. Parágrafo 1ro De las jornadas y descansos Art. 47.- De la jornada máxima. - La jornada máxima de trabajo será de ocho horas diarias, de manera que no exceda de cuarenta horas semanales, salvo disposición de la ley en contrario. Art. 50.- Límite de jornada y descanso forzosos. - Las jornadas de trabajo obligatorio no pueden exceder de cinco en la semana, o sea de cuarenta horas hebdomadarias. Los días sábados y domingos serán de descanso forzoso y, si en razón de las circunstancias, no pudiere interrumpirse el trabajo en tales días, se designará otro tiempo igual de la semana para el descanso, mediante acuerdo entre empleador y trabajadores. Art. 51.- Duración del descanso. - El descanso de que trata el artículo anterior lo gozarán a la vez todos los trabajadores, o por turnos si así lo exigiere la índole de las labores que realicen. Comprenderá un mínimo de cuarenta y ocho horas consecutivas. Art. 52.- Trabajo en sábados y domingos. - Las circunstancias por las que, accidental o permanentemente, se autorice el trabajo en los días sábados y domingos, no podrán ser otras que éstas: 

Necesidad de evitar un grave daño al establecimiento o explotación amenazado por la inminencia de un accidente; y, en general, por caso fortuito o fuerza mayor que demande atención impostergable.



La condición manifiesta de que la industria, explotación o labor no pueda interrumpirse por la naturaleza de las necesidades que satisfacen, por razones de carácter técnico o porque su interrupción irrogue perjuicios al interés público. Art. 55.- Remuneración por horas suplementarias o extraordinarias. - Por

convenio escrito entre las partes, la jornada de trabajo podrá exceder del límite fijado en los

32 artículos 47 y 49 de éste código, siempre que se proceda con la autorización del inspector de trabajo y se observen os siguientes prescripciones: 1. Las horas suplementarias no podrán exceder de cuatro en un día, ni de doce en la semana. 2. Si tuvieren lugar durante el día o hasta las 24H00, el empleador pagará la remuneración c orrespondiente a cada una de las horas suplementarias con más un cincuenta por ciento de recargo. Si dichas horas estuvieren comprendidas entre las 24H00 y las 06H00, el trabajador tendrá derecho a un ciento por ciento de recargo. Para calcularlo se tomará como base la remuneración que corresponda a la hora de trabajo diurno; 3. En el trabajo a destajo se tomarán en cuenta para el recargo de la remuneración las unidades de obra ejecutadas durante las horas excedentes de las ocho obligatorias; en tal caso, se aumentará la remuneración correspondiente a cada unidad en un cincuenta por ciento o en un ciento por ciento, respectivamente, de acuerdo con la regla anterior. Para calcular este recargo, se tomará como base el valor de la unidad de la obra realizada durante el trabajo diurno; y, 4. El trabajo que se ejecutare el sábado o el domingo deberá ser pagado con el ciento por ciento del recargo. Art. 61.- Cómputo de trabajo efectivo. - Para el efecto del cómputo de las ocho horas se considerará como tiempo de trabajo efectivo aquel en que el trabajador se halle a disposición de sus superiores o del empleador, cumpliendo órdenes suyas. 3.1.5.3 rmu. En el Instituto Ecuatoriano de Seguridad Social, existen dos regímenes definidos: servidores sujetos a la Ley Orgánica de Servicio Público y trabajadores amparados por el Código del Trabajo y la Contratación Colectiva. El IESS no reconoce ingresos adicionales a los establecidos en las normas legales vigentes; sus escalas se rigen por lo que determina la LOSEP, para el caso de los servidores y de acuerdo a lo que establece el Código del Trabajo y la Contratación Colectiva para los trabajadores. Artículo 267.- De las horas suplementarias Se considerarán horas suplementarias a aquellas en las cuales la o el servidor labore justificadamente fuera de su jornada legal de trabajo, hasta por cuatro horas posteriores a la misma y por un máximo de sesenta horas al

33 mes, pudiéndose realizar estas horas suplementarias entre la terminación de la jornada legal y las 24h00 del mismo día. La institución pagará por este concepto a la o el servidor público la remuneración correspondiente a cada una de las horas de trabajo de la o el servidor público más un veinte y cinco por ciento (25%) de recargo del valor de la hora con respecto a la remuneración mensual unificada. En caso de que los días sábados y domingos formen parte de la jornada legal de trabajo, las horas suplementarias se pagarán con el recargo del veinte y cinco por ciento (25%) del valor de la hora de remuneración mensual unificada. Artículo 268.- De las horas extraordinarias Se considerarán horas extraordinarias a aquellas en que la o el servidor labore justificadamente fuera de su jornada legal de trabajo, a partir de las 24h00 hasta las 06h00 durante los días hábiles; y, durante los días feriados y de descanso obligatorio; hasta por un máximo de sesenta horas al mes.

4 MARCO METODOLÓGICO 4.1 Diseño/Tipo de Investigación La presente investigación se basará en un enfoque cuantitativo, debido a lo que se busca en este documento es la objetividad y no la subjetividad, en donde sería de ayuda el enfoque cualitativo. El enfoque cuantitativo actuará además en la medición y análisis de los resultados obtenidos en las encuestas, buscando no cambiar la realidad de las observaciones mediciones realizadas. Otro factor muy importante para el uso del enfoque cuantitativo es el proceso estructurado y ordenado al que esta investigación apunta. Una vez definido el enfoque, el diseño de la investigación será no experimental, esto debido a que en este documento no existirá manipulación de alguna de las variables de estudio. La finalidad de este diseño de investigación es observar y estudiar cómo se comportan las variables en un ambiente regular y sin intervención de algún factor externo que no esté relacionado con la investigación, para luego ser analizadas cada uno de las situaciones que se han presentado en este contexto natural de este estudio. Se puede desglosar que este diseño de investigación además será transversal es decir que se recolectarán datos en un tiempo determinado, en otras palabras, los datos recogidos serán tomados en un único momento. En este documento así mismo se han definido tres tipos de investigación que son: Investigación Bibliográfica: Proporciona el conocimiento de investigaciones ya existentes. Este tipo de investigación se aplicará en la fundamentación teórica, basándose en fuentes bibliográficas confiables que no permitan sustentar el conocimiento adquirido, y a su vez encontrar nuevo conocimiento que resulte útil dentro de este documento, ya que no basta hacer uso solamente de lo sabido si no ir construyendo nuevos saberes en el camino y hacer uso de ellos. Investigación Descriptiva: Describe los hechos como son observados. Se aplicará en la recolección de información en la empresa, puesto que adicionalmente se necesita observar el objeto de estudio describiéndolo en una primera instancia, para luego comparar lo observado con lo recolectado.

35 InvestigaciĂłn Aplicada: Tipo de investigaciĂłn centrada en encontrar mecanismo o estrategias que permitan lograr un objetivo concreto. Este tipo de investigaciĂłn se aplicarĂĄ en le etapa de desarrollo del sistema debido a que se obtendrĂĄn nuevos conocimientos acerca del lenguaje de programaciĂłn seleccionado, y se pretende dar una soluciĂłn a la problemĂĄtica aplicando dichos conocimientos en el desarrollo del software.

4.2 PoblaciĂłn/Universo 4.2.1 PoblaciĂłn. La poblaciĂłn dentro de la investigaciĂłn es de 245 trabajadores de la CNEL â&#x20AC;&#x201C; EP Unidad de Negocio de Santo Domingo de los Colorados, estas 245 personas la conforman 3 distintos departamentos como son: pull financiero, centro de cĂłmputo y personal tĂŠcnico operativo. 4.2.2 Muestra. Para la muestra de la poblaciĂłn obtenida se ha hecho uso de la siguiente fĂłrmula estadĂstica que permite calcular la muestra:

đ?&#x2018;&#x203A;=

đ?&#x2018;§ 2 (đ?&#x2018;?.đ?&#x2018;&#x17E;) đ?&#x2018;§2 (đ?&#x2018;?.đ?&#x2018;&#x17E;)

đ?&#x2018;&#x2019; 2+

đ?&#x2018;

;đ?&#x2018;&#x203A;=

0.992 (245.245) 0.102 +

= 99

0.992 (245.245) 245

En donde: n= TamaĂąo de la muestra z= Nivel de confianza deseado en este caso 99% p= ProporciĂłn de la poblaciĂłn con la caracterĂstica deseada (ĂŠxito) q= ProporciĂłn de la poblaciĂłn sin la caracterĂstica deseada (fracaso) e= Nivel de error dispuesto cometer (10%) N= TamaĂąo de la poblaciĂłn. Una vez reemplazado todos los valores dentro de esta fĂłrmula estadĂstica se ha obtenido una muestra de 99 personas.

4.3 Técnicas e Instrumentos de Recogida de Datos 4.3.1 Técnicas. Las técnicas son muy importantes dentro de la investigación, debido a que estas abstraen de forma en su mayoría precisa la información necesaria y completa de lo que se pretende estudiar. Para ello dentro de esta investigación se optó por el uso de dos técnicas que son la entrevista y la encuesta. La entrevista es usada para obtener información preliminar para el desarrollo de la investigación, para así tener un bosquejo con lo que se ha de enfrentar este estudio. Estas entrevistas también servirán para enriquecer más de alguna forma a las encuestas, puesto que entre las dos técnicas existirá una relación mutua de apoyo. Las encuestas ayudan a obtener información importante de la muestra, y como el estudio tiene un enfoque cuantitativo los números que se recojan en esta técnica serán analizados objetivamente de parte los investigadores. Las encuestas en su totalidad serán preguntan cerradas de opción múltiple o de si/no esto una vez más debido al enfoque sobre el que ha recaído la investigación. 4.3.2 Instrumentos. El instrumento usado para la recolección de datos y como formato para las técnicas será el cuestionario, que quizás sea el instrumento más usado debido a su eficacia dentro de cualquier investigación. Este instrumento permitirá que en el análisis de los datos sea más fácil observar los números que arrojarán las encuestas y entrevistas.

4.4 Técnicas de Análisis de Datos Una vez realizada entrevistas y encuestas a los diferentes miembros de cada departamento se pretende analizar los datos mediante el uso de estos dos estadísticos centrales: 4.4.1 Media. Con ella se busca evidenciar un promedio de las repuestas que ofrece la muestra a los cuales se les ha realizado la encuesta y la entrevista.

37 4.4.2 Moda. 

Con este estadístico se busca encontrar cual es el problema más común que existe para la asignación de horas extraordinarias



Además de si los empleados ven positiva la implementación de un sistema móvil, para el beneficio de la empresa.



Destacando esto y otros como los factores más importantes a analizar dentro de las entrevistas y encuestas.

4.5 Metodología de Desarrollo Software El Manifiesto Ágil según Álvarez (2012), nació de varios autores debido a que solo existían metodologías que se concentraban mucho más en la documentación que en la programación, esto hizo que estos autores presten más atención a este último punto, y es así como nació este manifiesto ágil que en el día de hoy se ha convertido en una alternativa fundamental con la cual se puede trabajar. Este manifiesto Ágil busca seguir 4 principios fundamentales que son: 

Valorar a los individuos y sus iteraciones



Valorar más el software que funciona



Valorar más la colaboración con el cliente



Valorar más la respuesta al cambio Con el primer principio en este proyecto se tendrá mayor contacto con el cliente del

producto es decir los empleados de la empresa, cuestionándolos constantemente si el software está cumpliendo con los requerimientos que necesitan, así mismo con este principio el avance del software será presentado al departamento de sistemas al final de cada iteración en forma de un programa ya ejecutable. Esta metodológica además implica tener más en consideración que la aplicación funcione, de esta forma la aplicación tendrá más interés sobre la documentación del mismo. La aplicación se realizará en dispositivos móviles multiplataforma, por lo que es muy

38 importante realizar evaluaciones en la aplicación en los diferentes sistemas operativos ya sea IOS, Android y Windows Mobile. Sin duda los empleados de la empresa CNEL-EP Unidad de Negocio Santo Domingo, conforman una parte importante durante el desarrollo de este proyecto, puesto que representan al cliente, que dentro de esta metodología conforma un solo equipo con los desarrolladores, con esto se logrará un trabajo más confiable y satisfactorio para ambas partes. Por último, dentro del proyecto otro principio que juega un papel muy importante dentro de estas metodologías es el cambio, es decir que si los empleados de la empresa consideran que la aplicación no está encaminada a lo que ellos deseaban se realicen cambios de acuerdo a las necesidades que los empleados sugieran. Tabla 2 Comparativo ente las Metodologías Scrum y XP Metodologías Scrum

Metodología XP

Los cambios en Sprint no existen.

Pueden existir cambios, mientras el equipo no haya empezado a trabajar en algo en específico.

El equipo determina la secuencia de las tareas de

Las tareas siguen una secuencia de acuerdo a la

cada Sprint.

prioridad.

El Scrum Master es el responsable del código que se

El equipo puede reestructurar el código si entiende

haya escrito

que es necesario.

Las validaciones de software se realizan una vez que

Las validaciones ocurren todo el tiempo, siempre y

se completan todos los Sprints.

cuando el equipo así lo amerite.

Fuente: Tomado de “Ingeniería de software teoría y práctica” por Pfleeger Lawrence, S., 2002, Buenos Aires, Argentina: Pearson Education.

La siguiente tabla muestra un comparativo personal basada en la experiencia y estudio de la metodología Scrum y la metodología Xp.

39 Tabla 3 Comparativo entre Metodologías Parámetros

Estructura Metodológica

Desarrollo de Prioridades

Metodologías Scrum

Estructura

jerárquica

Metodología XP

más

Estructura mucho más cambiante y

organizada

menos organizada.

El equipo puede modificar el orden de

El equipo sigue estrictamente el

la prioridad para desarrollo de tareas

orden de prioridad de las tareas definidas por el cliente

Duración de iteraciones

Respuesta ante cambios

Las iteraciones de entrega son más

extensas oscilando de 2 a 4 semanas.

cortas, básicamente de 1 a 3 semanas.

Al terminar las tareas de los Sprints,

Las tareas que se van entregando al

cliente

las

que

conformidad

el no

dueño se

modificar.

aceptó

vuelven

son

modificadas

susceptibles en

cuanto

ser

dure

proyecto.

Por los siguientes motivos se ha optado por Scrum para el desarrollo del software, una vez planteado cada Sprint debe cumplirse a “carta cabal”, cada uno de ellos, por lo que no existirán cambios y pérdida de tiempo, otro factor es que las validaciones serán realizadas estrictamente luego de que se terminen cada uno de los Sprints a menos que en algún Sprint exista una tarea de validación; esto ayudará al programador/es preocuparse por las validaciones al final. 4.5.1 Scrum. Esta metodología pretende obtener resultados en iteraciones cortas, estas son entre una y cuatro semanas a los que se llaman Sprints, al final de cada uno de estos Sprints, se presentarán los avances al Product Owner que es un miembro del departamento de Sistemas de la CNEL- EP, esta persona representa al cliente (empleados del personal técnico), ya que su conocimiento en el área hará que sea un intermediario entre el equipo de desarrollo y los empleados técnicos operativos de la empresa. Además de que esta metodología de desarrollo ágil se centra mucho en el desarrollo del software lo que no sucede con una metodología ágil conocida como Kanban que según

40 Álvarez (2012) esta es muy valiosa para equipos de soporte o de cualquier otra área de investigación como en recursos humanos o departamentos financieros. Por lo que para el desarrollo de software resulta más útil el uso de Scrum. Una metodología ágil que también es muy usada dentro del desarrollo de software es la Programación Extrema (XP) que, según Brito, Sosa & Héctor (2011) al igual que Scrum busca potenciar la relación que debe existir con el cliente y el quipo haciendo uso de una continua retroalimentación con el cliente. Pero en XP el cliente tiene el poder total sobre las prioridades y no el equipo de desarrollo, pero en Scrum el equipo de desarrollo se encargar de elegir sus prioridades, por lo que Scrum resulta más idónea para ser utilizada en este proyecto. 4.5.1.1 roles en el equipo scrum. 4.5.1.1.1

product owner.

Como se ha mencionado en el apartado anterior, el Product Owner en la empresa será un trabajador del departamento de Sistemas. Se encarga de representar al cliente ante el equipo, capaz de hablar lenguaje de negocios y estar familiarizado con conceptos empleados por el equipo. Juega un papel crucial durante el proyecto ya que es responsable de su éxito o fracaso del mismo, debe ser capaz de transmitir al equipo los requisitos y reacciones del cliente es decir intermediario cliente-equipo, determina lo que se debe hacer y establece las prioridades para entregar el valor más alto, además de ser la persona que acepta o rechaza los entregables por parte del equipo en las revisiones de trabajo de cada Sprint 4.5.1.1.2

scrum master.

El Scrum Master es el otro elemento dentro del equipo Scrum, este busca ser el encargado de la productividad del equipo, esto lo realiza gracias a Daily Meeting que son reuniones diarias preguntando al equipo los inconvenientes y avances en el día de trabajo anterior. Como el equipo de desarrollo lo conforman dos personas se ha adaptado a que uno de estos desarrolladores también realice la función de Scrum Master, así al inicio de cada Daily Meeting las dos personas que conforman el equipo de desarrollo expondrán los avances, las dificultades y las tareas que están en proceso, aparte como ya menciono uno de ellos dirigirá estas reuniones tomando el papel de Scrum Master.

41 4.5.1.1.3

proceso scrum.

Álvarez (2012) define que este proceso se divide en dos grandes etapas: El Sprint 0, y los demás Sprints o iteraciones que son entregadas en Releases (Planificaciones de Entrega). 4.5.1.1.4

sprint 0.

El Sprint 0 es el primer sprint que se realiza con todo el equipo de desarrollo en este se hará una planificación del proyecto. En este los dos miembros del equipo buscarán detallar y planificar los recursos financieros, las herramientas para el desarrollo, el tiempo del proyecto, el número de Sprints que se realizarán etc. Aquí también el equipo determinará si el proyecto que se ha propuesto es viable o no. Entonces el objetivo principal del Sprint 0 es definir el contenido del trabajo, y esto como lo define Álvarez (2012) se va a conseguir por medio de una primera revisión al Product Backlog. El Product Backlog es el que contiene los requisitos principales del proyecto como: las funcionalidades principales, los productos generados, formatos etc. 4.5.1.1.5

sprints.

Los sprints representan las iteraciones que el equipo de desarrollo realizará durante el proyecto, en el Sprint 0 es donde se establece la duración que tendrá cada Sprint, generalmente suelen ser hasta un máximo de cuatro semanas. Cada que un Sprint finalice se hará una reunión con el Product Owner (Encargado de sistemas de la empresa) del avance del proyecto, el Product Owner además aceptará o no el avance del proyecto además de observar si el proyecto está encaminado de la forma en la que el cliente (los empleados) quiere que se realice. El Product Backlog describía las funciones que se pretende alcanzar en el desarrollo del proyecto, pero existe un subconjunto de estos que son Sprint Backlog en estos se termina un funcionalidad o funcionalidades que se pretenden alcanzar en un Sprint determinado. Antes de comenzar cada Sprint se debe hacer una planeación sobre este, a lo que se le denomina Sprint Planning, en donde se establece que tareas se debe realizar en dicho Sprint. 4.5.1.1.6

retrospectiva.

42 Según Álvarez (2012) para muchos esta reunión es la más importante dentro del proceso Scrum, la retrospectiva sirve para analizar cómo se están haciendo las cosas y como mejorar continuamente los procesos que se realizan en los Sprints. Muchas de las ocasiones estas reuniones suelen hacerse con el Scrum Manager y el equipo de desarrollo, pero si el Product Owner se ve afectado de alguna forma por estas reuniones es recomendable que asista. Retrospectiva del Sprint se enfoca en el equipo Scrum y comprende un proceso de evaluación de fortalezas y debilidades e identificando mejoras y creando un plan de mejora. Este proceso ocurre después de cada revisión del Sprint y antes de la próxima planificación del Sprint, así garantizando la productividad de cada reunión.

5 RESULTADOS 5.1 Análisis de resultados de Entrevista Entrevista dirigida al director del departamento Financiero de la Corporación Nacional de Electricidad-Empresa Pública. 1. ¿Cuáles son los inconvenientes de realizar el proceso de registro de horas extraordinarias de la forma en que se ha venido realizando? Los inconvenientes que se suelen ser más comunes son que muchas veces la información de un formulario de registro de horas extras no coincide con el que nosotros manejamos, por lo que siempre existe mucho trabajo al momento de revisar donde está el error y corregirlo. Además, que el usuario que realiza las horas extras muchas veces tiene que regresar a la empresa para registrarse. 2. ¿Cree usted que existe demora para el registro de horas extraordinarias y cuáles son sus inconvenientes que influyen en esa demora? No existe una demora debido a que cada informe que se presenta para el pago a los compañeros llega antes de la fecha de corte (quincenas), que suelen ser el 15 y el 30 de cada mes, lo que sí existe es demasiado trabajo por falta de coincidencias entre formularios. 3. ¿Qué políticas brinda la empresa para realizar horas extraordinarias? Las políticas que se manejan dentro del código de trabajo del Ecuador y algunas normas que se rigen en la Cnel. 4. ¿Cómo se realiza el proceso de registro de horas extraordinarias? El proceso de registro se realizada mediante formularios, existen 6 formularios ATH02, ATH-03, ATH-04, ATH-05, ATH-06 y ATH-07, cada uno de estos formularios depende del anterior exceptuando los formularios ATH-02 y ATH-04 que esos van dirigidos exclusivamente para el personal administrativo o el de oficina. Se empieza con el formulario ATH-03 en donde los profesionales de operación o agentes de agencia hacen una planificación de los trabajos que van realizarse, luego de culminado la elaboración de dicho

44 formulario se procede al ATH-05; en este formulario se calcula un pago tentativo dado a que es un pre-final del formulario ATH-06 y ATH-07 que son los finales. Luego el formulario ATH-05 llega a nosotros el departamento de Talento Humano en donde nosotros en base a esos datos elaboramos dos formularios consolidados que son los que sirven para el pago: el ATH-06 que es el consolidado por persona y el ATH-07 que es el consolidado por área o por dirección. 5. ¿Cómo se realiza el cálculo total de horas extraordinarias? El cálculo se lo realiza de forma manual, por lo que lleva mucho tiempo llegar a un registro en donde se vean reflejados las cantidades de dinero correspondientes para cada empleado técnico. 6. ¿El departamento Financiero cuenta con un software informático para el registro de horas extraordinarias? ¿En caso de poseer un software informático cómo se realizar el proceso de registro en el mismo? ¿En caso de no poseer un software informático cómo se mantiene la información organizada? No contamos con ningún sistema, simplemente nos manejamos con archivos de Excel que luego son guardados dentro de cada computadora en donde se esté elaborando el registro. 7. Al realizar una capacitación al personal sobre el uso de un sistema móvil en el registro de horas extras. ¿Qué beneficios cree usted que aportaría el realizar dicha capacitación? Sería un gran aporte debido a que siempre que se introduce algo nuevo se necesita enseñar a los demás como funciona o para que se hizo, al principio resultará difícil ya que se entrará en una etapa de adaptación ante el nuevo modelo de registro. 8. Si la empresa cuenta con un sistema móvil empresarial que automatice este proceso de registro. ¿Cree usted que de alguna forma facilitaría un poco más su trabajo y en qué sentido lo haría? Lo facilitaría porque no tendré que estar realizando tantos cálculos, más bien el sistema me ayudaría a reflejar donde hay errores y si es necesario corregirlos si por algún motivo no concuerda algo. Pero sí creo que facilitaría las cosas.

45 Análisis de la Entrevista En la entrevista realizada se ha podido evidenciar que el proceso en que se maneja el registro de horas extras es muy extenso, debido a que muchas veces el personal de talento humano ocupa gran parte de su tiempo en el cálculo de las cantidades que el empleado a de recibir, este es un factor por el que resulta conveniente el realizar este proceso de forma automática. Además, la empresa no cuenta con ningún software que le facilite este proceso, por lo que se pretende ser pioneros en este tema en particular. Otro factor que se rescató de la entrevista es que el empleado que muchas veces es el que se registra tiene que acudir a la empresa para que conste sus horas realizadas, esto es una pérdida de tiempo.

5.2 Análisis de resultados de Encuesta 1. Posee un teléfono inteligente (Smart-phone)? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 3 Posesión de un Teléfono Inteligente Variable Si No

Porcentaje 87 12

La siguiente figura representa los porcentajes de la pregunta número 1. Pregunta 1

No 4% Si Si 96%

Figura 9. Porcentajes de respuestas de la pregunta 1

46 Análisis: La gran mayoría de la muestra refleja que, si poseen un teléfono inteligente o Smart-phone, mientras que solo un 4% no lo tiene, por lo que ese 4% debería realizar el registro en un ordenador. 2. Le resulta fácil el uso teléfonos inteligentes (Smart-phone)? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 4 Uso fácil de un teléfono inteligente Variable Si No

Porcentaje 75 24

La siguiente figura representa los porcentajes de la pregunta número 2.

Pregunta 2

24%

76%

Figura 10. Porcentajes de respuestas de la pregunta 2

Análisis: El 76% de la muestra refleja una gran habilidad al momento de usar algún Smart-phone por lo que este es un segundo hecho para seguir adelante con el proyecto.

47 3. ¿Utiliza su Smart-phone para resolver proyectos enfocados en el trabajo de la empresa? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 5 Smarth-phone enfocados al trabajo Variable Si No

Porcentaje 46 53

La siguiente figura representa los porcentajes de la pregunta número 3.

Pregunta 3

54%

46% Si No

Figura 11. Porcentajes de respuestas de la pregunta 3

Análisis: El 54% de la muestra no usa su Smart-phone para resolver algún inconveniente laboral, este hecho obliga a incentivar el uso de este dispositivo en el ambiente labora debido a que suele ser de gran ayuda en la resolución de problemas

48 4. ¿Qué tipo de sistema operativo posee Smart-phone? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 6 Tipo de Sistema Operativo Variable Android IOS Windows Mobile

Porcentaje 83 12 4

La siguiente figura representa los porcentajes de la pregunta número 4.

Pregunta 4

12%

4% Android IOS Windows Mobile

84%

Figura 12. Porcentajes de respuestas de la pregunta 4

Análisis: Aunque el gran predominante es el sistema operativo de nativo de Samsung: Android, lo que se busca es una inclusión con todo el personal, por lo que el sistema a desarrollarse será multiplataforma.

49 5. ¿Utiliza aplicaciones móviles (nativas o híbridas) impartidas por la misma empresa? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 7 Aplicaciones impartidas por la empresa Variable Si No

Porcentaje 0 99

La siguiente figura representa los porcentajes de la pregunta número 5.

Pregunta 5

Si No

100%

Figura 13. Porcentajes de respuestas de la pregunta 5

Análisis: Ninguna aplicación móvil ha estado dirigida para el personal administrativo por parte de la empresa, por lo que se buscará ser pioneros con estos usuarios y que así se descubran los beneficios del uso de aplicativos en un sistema móvil.

50 6. ¿Cree usted que existe pérdida de tiempo en el registro de horas extraordinarias? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 8 Pérdida de tiempo registro de horas extras Variable Si No

Porcentaje 93 6

La siguiente figura representa los porcentajes de la pregunta número 6.

Pregunta 6

Si No

94%

Figura 14. Porcentajes de respuestas de la pregunta 6

Análisis: Debido a que la gran mayoría del personal demuestra inconformidad con la agilidad actual del registro, el uso de una app móvil pretende organizar y mejorar la velocidad en el registro de horas extraordinarias.

51 7. Existe pérdida de tiempo al momento de pedir información o documentos relacionados con horas extraordinarias En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 9 Pérdida de tiempo al solicitar información

Variable Si No

Porcentaje 92 7

La siguiente figura representa los porcentajes de la pregunta número 7.

Pregunta 7

Si No

94%

Figura 15. Porcentajes de respuestas de la pregunta 7

Análisis: El 94% de los trabajadores una vez más no se encuentra conforme con el tiempo empleado para el registro de horas extraordinarias, por lo que es otro factor para seguir en marcha con el proyecto.

52 8. ¿Le gustaría contar con una sistema móvil para registro de horas extras? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 10 Sistema Móvil para registro de horas extras

Variable Si No

Porcentaje 71 28

La siguiente figura representa los porcentajes de la pregunta número 8.

Pregunta 8

28%

72%

Figura 16. Porcentajes de respuestas de la pregunta 8

Análisis: El 28% de la muestra presenta un ligero miedo al cambio, pero los cambios suelen ser buenos y este encaminara a la empresa a un mejor desarrollo. Mientras tanto la gran mayoría si quiere una aplicación móvil para el registro.

53 9. ¿Cree usted que el desarrollo de dicho sistema móvil facilitaría el proceso de registro? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 11 Facilitar el proceso de registro

Variable Si No

Porcentaje 73 26

La siguiente figura representa los porcentajes de la pregunta número 9.

Pregunta 9

26%

74%

Figura 17. Porcentajes de respuestas de la pregunta 9

Análisis: El 74% de la muestra piensa que este sistema móvil de alguna manera ayudará a el registro y así facilitarlo, mientras un 26% aún se mantiene en que no es necesario.

54 10. ¿Estaría de acuerdo en contar con un sistema móvil que le permita agilizar dicho proceso de registro de horas extraordinarias? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 12 Sistema Móvil para agilización de procesos

Variable Si No

Porcentaje 72 27

La siguiente figura representa los porcentajes de la pregunta número 10.

Pregunta 10

27%

73%

Figura 18. Porcentajes de respuestas de la pregunta 10

Análisis: El 73% de la población cree que además la implementación de este sistema ayudará a que se agilicen los registros en comparación con el que se mantiene en la actualidad, mientras un 27% cree que el sistema no agilizará dicho registro.

55 11. ¿Cree Usted que el departamento de Talento Humano cumple con los requisitos del Control de Personal en sus horas extras? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 13 Cumplimiento de Requisitos Horas extras

Variable Si No

Porcentaje 96 3

La siguiente figura representa los porcentajes de la pregunta número 11.

Pregunta 11

Si No

97%

Figura 19. Porcentajes de respuestas de la pregunta 10

Análisis: El 97% de la población se encuentra de acuerdo con los requisitos que sostiene el departamento de Talento Humano para el control en el registro de horas extras, por lo que es muy importante seguir manteniendo esos requisitos en la aplicación móvil.

56 12. ¿Está usted conforme con el proceso actual de registro de horas extraordinarias? En la siguiente tabla se ven reflejadas la cantidad de personas que escogieron una repuesta. Tabla 14 Conformidad con el proceso actual de registro

Variable Si No

Porcentaje 64 35

La siguiente figura representa los porcentajes de la pregunta número 12.

Pregunta 12

35%

65%

Si No

Figura 20. Porcentajes de respuestas de la pregunta 10

Análisis: Un 35% de la muestra aún no se muestra del todo conforme con el proceso general de registro de horas extraordinarias, por lo que se pretende reducir ese porcentaje con el uso de la aplicación móvil, ya que lo que se busca es alcanzar un alto grado de satisfacción por parte del cliente.

5.3 Aplicación de la Metodología en el Software 5.3.1 Planificación. Documento de especificación de requerimientos En el presente documento se encontrará la información acerca de los diferentes tipos de requerimientos producto de software, interfases del usuario, interfases del sistema, características de los usuarios, descripción de los requerimientos funcionales, no funcionales y del sistema, los cuales se representarán a continuación: 5.3.1.1.1. requerimientos de usuario. Enunciados en lenguaje natural por parte del usuario acerca de lo que se espera obtener: 

El Sistema Web debe automatizar el proceso de registro y cálculo de horas extraordinarias en la Corporación Nacional de Electricidad – Empresa Pública.



El Sistema Web debe brindar servicio de reportería de acuerdo a formatos impuestos por la empresa que automatice el proceso manual de reportería.

5.3.1.1.2. requerimientos de sistema. Descripción más detallada de los servicios y lo que hay que operar: Módulos: 

Cálculo de pago de horas extraordinarias.



Empleados



Áreas



Departamentos



Cargos



Tipo de Leyes



Tipo de Nóminas



Etapa funcional

58 

Tarifario



Calendario de Feriados

5.3.1.1.3. requerimientos de arquitectura. Presenta en detalle las herramientas impuestas por la empresa con las se debe trabajar durante el proyecto: 

Desarrollo de un Sistema Web con capacidad para adaptarse a los diferentes dispositivos desde los que puede ser consultado.



Sistema Web accesible desde cualquier navegador (Firefox, Google Chrome, Microsoft Edge, etc.).



El Sistema debe utilizar base de datos Oracle 11g En esta etapa para los roles de la metodología Scrum ha quedado definida de la

siguiente manera: Tabla 15 Roles Scrum Roles Scrum Master Equipo de desarrollo Product Owner Coach

Encargados Sr. Luis Arequipa Sr. Luis Arequipa y Bryan Meza Ing. Yahaira Vintimilla Sr. Bryan Meza

Para el Sprint 0 se realizó una reunión entre los implicados en el proyecto Product Owner que en esta casa el cliente lo es, el equipo de desarrollo y el Scrum Master. Lo que se trata de definir en el Sprint 0 es la planeación que se tendrá a lo largo del trabajo, es decir: herramientas necesarias para el desarrollo, número y duración de los Sprints, cuando iniciar el proyecto, definir el reléase plan o el plan de entrega y primeras versiones de los artefactos que se usarán a lo largo del proyecto, como son: product backlog y los sprint backlog, en cuanto a los incrementos que también es otra artefacto se verán afectados en el transcurso de que una tarea este “Hecha”. Esta planeación antes de comenzar con el Sprint 0 tuvo una duración de total 8 horas, en donde la mitad de esas horas fue con la intervención del Product Backlog (cliente) y el resto entre el equipo de desarrollo y el Scrum master.

59 En la primera reunión con de cuatro horas se definió una primera versión del Product Backlog, con su número de historias prioridad y estimación. Para ello se contó con todo los involucrados debido a que el Product Owner (cliente) especificaba la funcionalidad que se deseaba tener el software y el equipo de desarrollo era el encargado de traducir eso a historias de usuario, además no se identificaron épicas ni temas debido a que el proyecto es algo en específico y su división fue en partes pequeñas en este caso las historias de usuario. 5.3.1.1 definición del product backlog. Tabla 16 Product Backlog N°

Historias de Usuario

Prioridad

Estimación

Interfaz de Login

Creación de Módulos

Registro de Conteo de horas trabajadas

Funcionalidad de editar y eliminar

Creación de Formularios ATH (02,03,04,05,06 y 07)

Generación de Reportes en 2 formatos

Caja de búsqueda rápida

Para fijar cuales serían las historias de usuario, se pidió a los interesados clientes incluido el Product Owner cuál era la funcionalidad que debía tener el sistema, por ello se definieron un total de 8 historias de usuarios, uno vez escritas se continuó con la prioridad de cada una de ellas. Para la prioridad se usó priority póker o póker de prioridad que es una de las técnicas más fáciles de usar para determinar la prioridad, en lo que consiste esta técnica es en

60 enumerar cartas del 1 al 9, siento el 0 lo más bajo y nueve lo más alto en donde el Product Owner escogió una de ellas la más conveniente para asignar una prioridad para cada historia. Dentro de la estimación se usó una métrica muy usada en Scrum son los puntos de historia, estos determinarán la complejidad que cada historia tendrá para el equipo de desarrollo, la estimación de igual forma que en la prioridad se usaron cartas, pero esta vez usando la serie Fibonacci, es decir estuvieron enumeradas de la siguiente forma 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 y un signo de interrogación (?), siendo el 0 la más baja complejidad 100 la más alta y el signo de interrogación no tener una idea clara de que valor asignar. En este proceso intervino el equipo de desarrollo y Scrum Master, ahora aquí no se obtienen una suma de las cartas, mientras que aquí se escoge la carta más repetida o un promedio de los números elegidos. 5.3.1.2 definición de las herramientas para el desarrollo. 5.3.1.2.1

front-end.

Para el front End se usará el framewrok de diseño llamada Laravel bajo la normativa de Material Desing porque se busca un sistema responsivo (que se adapte a cualquier dispositivo como: laptops, Smart-phones, tablets, etc.), gracias a ello el sistema será amigable con el usuario y tendrá un diseño intuitivo para su fácil uso. 5.3.1.2.2

back-end.

Para el Back-End se utilizará Php como código principal para toda la funcionalidad del sistema y para la base de datos Oracle, debido a que este fue un requisito explícito de la empresa. Además de un servidor local Apache, con el uso de XAMPP, en algunos casos. 5.3.1.3 número, definición y duración de los sprints. En la reunión del Sprint 0 se fijaron 3 Sprints que tendrán una duración de 3 a 5 semanas dependiendo de cada Sprint, la duración se detalla a continuación: Tabla 17 Definición de los Sprints

Número de Sprint Sprint 1 Sprint 2 Sprint 3

Duración 3 semanas 4 semanas 3 semanas

61 Cada semana representa 5 días de trabajo de lunes a viernes, y cada día fue de 3 horas. Para cada Sprint se asignaron historias por igual, es decir un total de 8 historias repartidas en 3 historias para el primer Sprint, 3 Historias para el segundo Sprint y 2 para el último Sprint. De esta forma se definieron los Sprint y los Sprint Backlog se detallan en anexos. 5.3.1.4 definición de dailys meetings, sprint planning, sprint review y retrospective. 5.3.1.4.1

daily meeting.

Los Dailys Meeting se realizarán al inicio de cada día de trabajo, la duración que tendrá cada Daily Metting es tentativamente un promedio media hora entre el equipo de desarrollo y el Scrum Master, en cada una de estas se presentarán las dificultades y los avances que se va obtenido día tras día. 5.3.1.4.2

sprint planning.

Estas reuniones se realizarán al inicio de cada Sprint, con el objetivo de que sirvan como una introducción para cada iteración, la realización de este tendrá una duración de 1 hora máximo para cada Sprint. Dependiendo de la complejidad de las Historias dentro de un Sprint la duración de la reunión podrá ser más larga o más corta, pero lo aconsejable es no superar el límite, debido a que representaría menos horas de trabajo dentro del Sprint. 5.3.1.4.3

sprint review.

La Sprint Review se realizarán una vez culminado un Sprint, en ella se detectarán si el equipo está cumpliendo con las tareas en cada Sprint o si existe inconformidad por cómo se realizó una tarea, si esto último sucede el siguiente Sprint será el encargado de corregir aquello. Dentro de esta reunión es importante que en esta reunión asista el Product Owner (cliente) debido a que él se encargará de decidir si se han alcanzado o no las metas en un Sprint en concreto. 5.3.1.4.4

retrospectiva.

Esta reunión se considera una de las más importantes y es aquí donde se hará una retroalimentación de cada Sprint, observando y detallando que cosas está bien, cuales son las cosas que se deben mejorar para la siguiente iteración y que se ha aprendido de ese Sprint. En esta reunión pueden asistir todos los involucrados en el sistema.

62 5.3.2 Desarrollo del Sprint 1. Para el primer Sprint se realizaron 3 historias de usuario que fueron distribuidas de la siguiente manera: Tabla 18 SprinBacklog 1 N° Historia 1 Interfaz de Login y página principal

Estimación 5 0.5 1 5 1 0.5

Creación de Módulos

1 5 8

Módulo de conteo horas extras

8 5 8 5 1 1 8 2 8

Tareas del Sprint Estructura y Creación Base de datos en Oracle Maquetado de la Interfaz y pagina inicial con moqups Creación del diseño de la Interfaz Programar la conexión con BDD con el framework y el oci8 de Php Crear todas las pestañas de la página inicial Hacer pruebas de conexión y validación Maquetado de los Módulos con moqups Creación de los módulos con registro y listado Verificación con Base de datos en Oracle Registros en cada módulo Calendario en módulo de empleado Listado en cada módulo Validación y pruebas Maquetado del Módulo con moqups Creación del Módulo con cajas de texto y botones Programación de la resta de horas Verificación con Base de datos en Oracle Validación y pruebas

Responsable

Apoyo Bryan

Luis

Estimación

13 Bryan

Bryan Luis

40 Bryan

Bryan

El trabajo de este Sprint comenzó el 13 de noviembre de 2017 y se dio por finalizado el 13 de diciembre del mismo año, como se puede observar en la siguiente tabla y figura que muestra su avance:

63 5.3.2.1 burndown chart sprint 1.

Interfaz de Login

1 2 3 4 5 6

Creación Módulos

1 2 3 4 5 6 7

Módulo de conteo horas extras

1 2 3 4 5

Estructura y Creación Base de datos en Oracle Maquetado de la Interfaz y pagina inicial con moqups Creación del diseño de la Interfaz Programar la conexión con BDD con el framework y el oci8 de Php Crear todas las pestañas de la página inicial Hacer pruebas de conexión y validación Maquetado de los Módulos con moqups Creación de los módulos con registro y listado Verificación con Base de datos en Oracle Registros en cada módulo Calendario en módulo de empleado Listado en cada módulo Validación y pruebas Maquetado del Módulo con moqups Creación del Módulo con cajas de texto y botones Programación de la resta de horas Verificación con Base de datos en Oracle Validación y pruebas Total de Horas Restantes Total de Horas Estimadas

1 3

3 3

2 3

3 2 1

5 1

4 6.13

1 3.067

2 46 46

1/12/2017

30/11/2017

29/11/2017

28/11/2017

27/11/2017

24/11/2017

23/11/2017

22/11/2017

21/11/2017

20/11/2017

17/11/2017

16/11/2017

15/11/2017

14/11/2017

Tarea

13/11/2017

Total Horas

Historia

Número Tareas

Tabla 19 BurndownChart del Sprint 1

43 42.9

41 39.9

38 36.8

35 33.7

32 30.7

29 27.6

26 24.53

20 21.5

18 18.4

15 15.33

12 12.27

9 9.2

0,5 0,5 2 -2 0

Burndown Chart Sprint 1 50 45 40

Puntos de historia

35 30 25 20 15 10 5 0 -5

Restantes Figura 21. Burndown Chart Sprint 1

8 DĂŹas

Estimadas

65 Este Sprint es el más fuerte del desarrollo debido a que se incluyó historias fuetes desde un inició, para tratar de aminorar la carga al equipo de desarrollo, este Sprint se dividió en 3 historias de usuario que son: Interfaz de login y página principal, además del diseño de la base de datos que fue fundamental, esta se la realizo con la normalización de documentos que facilitó la empresa, donde la tabla más fuerte es la de empleado, además de crear una tabla para migraciones no relacionada. En general se trató de seguir el número de horas propuestas por el equipo desde un inició además del trabajo diario de 3 horas, pero en la última historia surgieron un poco de dificultades por lo que al final se acumuló la carga de tareas por lo que el gráfico de avance o Burndown Chart se vio afectado por dos horas, lo cual no resulta una demora significativa, pero igual se la debe tener en cuenta. El resto de las historias se las cumplió con normalidad cumpliendo las exigencias de la empresa a la que se le está realizando este producto. Por último, se hizo una reunión con el Product Owner para presentar los avances, y una retrospectiva con el grupo para prevenir errores en el próximo Sprint.

Figura 22. Modelo Entidad Relación Base de Datos

La siguiente figura muestra el login del sistema:

Figura 23. Login del Sistema

La siguiente figura muestra los módulos del sistema:

Figura 24. Módulos del Sistema

La siguiente figura muestra únicamente el módulo de horas extras:

Figura 25. Módulo de Conteo de Horas

5.3.3 Desarrollo del Sprint 2 Para el primer Sprint se realizaron 3 historias de usuario que fueron distribuidas de la siguiente manera: Tabla 20 SprintBacklog 2 N° Historia 4

Estimación 8 8

Funcionalidad de editar y eliminar

10 10 4

Creación Formularios (02,03,04,05,06 y 07)

5 8 5 5 8 8 1

Tareas del Sprint Conexión de cada módulo con la Base de datos de Oracle Añadir en cada listado de los módulos un botón para editar y eliminar Programar la Funcionalidad del editar. Programar la Funcionalidad del eliminar. Hacer pruebas dentro de la BDD Copiar el formato proporcionado Conectar cada formulario con los datos de los módulos Programar el formulario para edición Crear botón para guardar la edición Conectar cada Formulario con la BDD Verificar el funcionamiento en el front-end y back-end Hacer validaciones y pruebas

Responsable

Apoyo Bryan

Luis

Estimación

20 Bryan

Luis

Bryan

Para el desarrollo del segundo Sprint se dio inicio el 4 de diciembre de 2017 y se finalizó el 12 de enero de 2018, como se muestra en la siguiente tabla y figura que muestra su avance:

68 5.3.3.1 burndown chart sprint 2.

Creación Formularios (02,03,04,05,06 y 07)

Programar el formulario para edición Crear botón para guardar la edición Conectar cada Formulario con la BDD

Verificar el funcionamiento en el front-end y back-end

Hacer validaciones y pruebas

Total de Horas Restantes

Total de Horas Estimadas

58,9

55,8

52,7

49,6

46,5

43,4

40,3

37,2

34,1

27,9

24,8

21,7

18,6

15,5

12,4

9,3

6,2

3,1

1 2 3 4 5

2 1

12/01/2018

11/01/2018

10/01/2018

9/01/2018

Hacer pruebas dentro de la BDD Copiar el formato proporcionado Conectar cada formulario con los datos de los módulos

8/01/2018

22/12/2017

21/12/2017

Programar la Funcionalidad del eliminar.

20/12/2017

19/12/2017

18/12/2017

Programar la Funcionalidad del editar.

15/12/2017

11412/2017

11312/2017

12/12/2017

11/12/2017

Funcionalidad de editar y eliminar

8/12/2017

5/12/2017

Tarea

7/12/2017

4/12/2017

Conexión de cada módulo con la Base de datos de Oracle Añadir en cada listado de los módulos un botón para editar y eliminar

Historia

6/12/2017

Total de Horas

Número Tareas

Tabla 21 Burndown Chart del Sprint 2

Burndown Chart Sprint 2 70

PUNTOS DE HISTORIA

60 50 40 30 20 10 0

-10

DIAS Restantes

Figura 26. Burndown Chart Sprint 2

Estimadas

70 Este Sprint representó muchos problemas en cuanto el tiempo y las horas que se establecieron al principio del mismo debido a que, algunas tareas se las realizaron en menor tiempo y otras en más tiempo, al ser dos historias de usuario pero con un estimación alta se les dio una duración a este Sprint de 4 semanas, pero él aunque el margen se mantuvo el ritmo de horas trabajadas diarias no, además se puede observar el grafico que la línea del progreso está por encima de la ideal, lo que quiere decir que se ha dado muy poco tiempo para lagunas tareas, por lo que el equipo tuvo uno carga excesiva en cada día de trabajo. Como resultado hubo pequeños detalles que se podrán pulir en el siguiente Sprint por la mala planificación de este. Pero se lograron los objetivos funcionales de las 2 historias de este Sprint. Esta vez la reunión con el Product Owner fue diferente debido a pequeños detalles que no se ha podido realizar, pero a su vez estaba satisfecho por la funcionalidad que tiene el sistema una vez finalizado este Sprint. La retrospectiva duro 2 horas en esta ocasión por los errores cometidos que no se ha podido prevenir, en esta reunión se expusieron las posibles razones y motivos por el que el desarrollo fue tan irregular, y porque en algunos días no se cumplió con el mínimo de 3 horas de trabajo. La siguiente figura muestra el botón eliminar y editar dentro del sistema.

Figura 27. Editar y eliminar

La siguiente figura muestra la reportaría en formato Excel.

Figura 28. Formularios de la empresa ATH´S

71 5.3.4 Desarrollo del Sprint 3. Para el primer Sprint se realizaron 3 historias de usuario que fueron distribuidas de la siguiente manera: Tabla 22 SprintBacklog 2 N° Historia Generación de Reportes en 2 formatos

Estimación 8 2 1

Caja de Búsqueda Rápida

2 2 8 1 2

Tareas del Sprint Usar el motor de las plantillas Blade para añadir formato PDF Con larvel añadir el formato de los formularios en excel Crear botones de generación de reportes Hacer Pruebas y validar. Crear la caja de texto para la búsqueda Programar el algoritmo de búsqueda Crear botón de búsqueda Hacer Pruebas

Responsable

Apoyo

Estimación

Luis Bryan

Bryan

Luis

El trabajo de este Sprint comenzó el 15 de enero de 2018 y se dio por finalizado el 2 de febrero del mismo año, como se puede observar en la siguiente tabla y figura que muestra su avance:

72 5.3.4.1 burndown chart sprint 3.

1.5

24/01/2018

17/01/2018

16/01/2018

2/02/2018

1/02/2018

31/01/2018

30/01/2018

29/01/2018

Caja de Búsqueda Rápida

26/01/2018

-1

19,6

18,2

16,8

15,4

12,6

11,2

9,8

8,4

5,6

4,2

2,8

1,4

25/01/2018

23/01/2018

22/01/2018

Usar el motor de las plantillas Blade para añadir formato PDF Con laravel añadir el formato de los formularios en Excel Crear botones de generación de reportes Hacer Pruebas y validar errores Crear la caja de texto para la búsqueda Programar el algoritmo de búsqueda Crear botón de búsqueda Hacer Pruebas Total de Horas Restantes Total de Horas Estimadas

19/01/2018

18/01/2018

Generación de Reportes en 2 formatos

15/01/2018

Tarea

Total de Horas

Historia

Número Tareas

Tabla 23 Burndown Chart del Sprint 3

5 0.5

0.5

6 0.5

Burndonw Chart Sprint 3 25

PUNTOS DE HISTORIA

0 1

-5

DÃ&#x152;AS Restantes

Figura 29. Burndown Chart Sprint 3

Estimadas

74 En la siguiente figura se muestra los botones de Copy, Excel y PDF, que permiten descargar las nóminas en ese formato y también la búsqueda rápida.

Figura 30. Generación de Reportes y búsqueda rápida

En este Sprint el tiempo sobro debido a que las tareas se realizaron rápidamente con la ayuda del Framework que incorpora estas características, además el tiempo que resto se le dio prioridad a los detalles no concluidos en el Sprint 2, en su gran mayoría tenían que ver con el Front-end, es por ello que en esta etapa se aprovechó dicho tiempo realizando estas actividades. La retrospectiva fue muy buena al final, aunque no siempre es bueno que el tiempo sobre, pero esta vez fue de gran ayuda. Con este Sprint se da por finalizado la realización de producto para la empresa, pero el proyecto aún tiene más desarrollo por parte de la documentación necesaria para el funcionamiento del sistema y demás detalles. 5.3.5 Desarrollo de Pruebas de aceptación. Las pruebas de aceptación fueran realizadas en función de cada una de las historias de usuario, es decir cómo se obtuvieron 7 historias existen 7 pruebas, en ellas se detallan los parámetro, condiciones y requisitos para la funcionalidad de cada una de las historias, además con esto se constata si se logra alcanzar los activos de cada una de las tareas que se detallan en el Sprint, para la aceptación de estas pruebas el Product Owner es el actor principal el que usa la funcionalidad y acepta que las tareas han sido correctas. En Anexos se detallan cada una de ellas.

5.4 Análisis de Impacto El análisis de impacto suele utilizarse mucho en proyectos bien documentados, debido a que este tipo de análisis verifica si los cambios que ha traído el nuevo proyecto, investigación o producto a de repercutir de forma positiva o negativa en alguna organización, es por ello que se ha desarrollado este análisis de impacto, para evidenciar esto, aquello de

75 indicadores que medirĂĄn la recepciĂłn del producto software dentro la empresa CNEL-EP Unidad de Negocio Santo Domingo. A continuaciĂłn, se mostrarĂĄ una tabla en la cual se pueden analizar el nĂşmero de niveles que se podrĂĄn otorgar a cada indicador usando como referencia nĂşmeros negativos para representaciĂłn negativa, nĂşmeros positivos para la representaciĂłn positiva y el cero como valor neutro darĂĄ a entender que no hubo impacto. El valor -3 serĂĄ el valor mĂĄs alto dentro del nivel negativo, mientras tanto el 3 representarĂĄ el valor mĂĄs alto del nivel positivo. Tabla 24 Niveles de Impacto Nivel -3 -2 -1 0 1 2 3

DescripciĂłn Impacto de alto nivel negativo Impacto de medio nivel negativo Impacto de bajo nivel negativo No hay impacto Impacto de bajo nivel positivo Impacto de medio nivel positivo Impacto de alto nivel positivo

En esta secciĂłn existirĂĄ anĂĄlisis de impacto social, tecnolĂłgico ambiental y econĂłmico, cada uno de ellos tendrĂĄn indicadores y estos a su vez un nivel representado por â&#x2C6;&#x2018;

una x, la fĂłrmula que determinarĂĄ el impacto serĂĄ đ??ź = đ?&#x2018;&#x203A; ; donde â&#x2C6;&#x2018; representa la sumatoria de cada valor de los niveles y đ?&#x2018;&#x203A; representa el nĂşmero de indicadores que habrĂĄ en cada tabla. Para toda esta llevar a cabo el anĂĄlisis de impacto se usaron cuatro tablas para cada uno de los impactos, y estos se detallan a continuaciĂłn. 5.4.1 Impacto Social. Tabla 25 Impacto Social Nivel de impacto Indicadores Disponibilidad de la informaciĂłn Privacidad de la informaciĂłn Integridad de la informaciĂłn Confiablidad de la informaciĂłn Total Sumatoria ÎŁ Total Resultado

--3

--2

--1

2 X X X

X X X

2 9 ÎŁ = 11 11 đ??ź = = 2.75 4 Impacto de alto nivel positivo

Algunos de los indicadores tienen que ver con la calidad dentro de un desarrollo de software, la informaciĂłn siempre va a estar disponible, pero si ocurre alguna eventualidad

76 externa como daĂąos en el servidor, falta de conexiĂłn a internet, entre otras se verĂĄ afectada por eso su nivel no es alto, mientras tanto la informaciĂłn serĂĄ privada para cada usuario, la informaciĂłn no serĂĄ corrupta o alterada sin autorizaciĂłn y por ende serĂĄ confiable. 5.4.2 Impacto TecnolĂłgico. Tabla 26 Impacto TecnolĂłgico Indicadores Nivel de impacto AutomatizaciĂłn de procesos Uso de herramientas tecnolĂłgicas Sistema interactivo con el usuario Total Sumatoria ÎŁ Total Resultado

--3

--2

--1

2 X X X

3 X

4 3 ÎŁ=7 7 đ??ź = = 2.33 3 Impacto de alto nivel positivo

Fuente: Autores

En esta tabla en el indicador de automatizaciĂłn de procesos, la mayorĂa de los procesos serĂĄn automatizados, es indispensable el uso de herramientas tecnolĂłgicas para que funcione el sistema, en cuanto a un sistema interactivo dependerĂĄ mucho del usuario al cada uno tener diferentes percepciones, unos se sentirĂĄn cĂłmodos con el sistema y otros quizĂĄs no tanto. 5.4.3 Impacto Ambiental. Tabla 27 Impacto Ambiental Indicadores Nivel de impacto DisminuciĂłn de hojas impresas Materiales de Oficina Total Sumatoria ÎŁ Total Resultado

--3

--2

--1

2 X X 2

3 X 3

ÎŁ=5 5 đ??ź = = 2.5 2 Impacto de alto nivel positivo

Con el uso del sistema este serĂĄ capaz de mostrar de manera digital el registro de horas trabajadas por los empleados, desechando los registros manuales en formatos impresos en hojas que no contribuĂan con una disminuciĂłn en la huella de contaminaciĂłn al planeta, ademĂĄs el uso de otros materiales desechables como grapas, borradores, esferos, ayudarĂĄn a que estos materiales (que a lo largo resultan difĂcil de degradarse) no sean ocupado para ningĂşn fin.

77 5.4.4 Impacto Económico. Tabla 28 Impacto Económico Indicadores Nivel de impacto Inversión de un servidor Disminución en el uso de materiales de oficina Total Sumatoria Σ Total Resultado

--3

--2

--1 X

X -1

X 3

Σ=2 2 𝐼= =2 2 No hay impacto

El indicar débil es que la empresa tendrá que correr con el gasto de un servidor, pero no hay que ver esto como un gasto, más bien como una inversión que se verá recompensada con eficiencia y eficacia en la empresa que a la larga generará más dinero Por otro lado, se reduce al mínimo materiales físicos, solo el uso indispensable de un dispositivo con conexión a internet. 5.4.5 Impacto General. Tabla 29 Impacto General Indicadores Nivel de impacto Impacto Tecnológico Impacto Social Impacto Ambiental Impacto económico Total Sumatoria Σ Total Resultado

-3

-2

-1

X -1

2 Σ=8 8 𝑁𝐼 = = 2 4 Impacto de positivo

alto

3 X X X 9

medio

nivel

Una vez realizado los cuatro puntos del análisis de impacto, se ha obtenido un nivel medio de impacto positivo lo que al fin repercute para ayudar a la empresa en el ahorro, la automatización, la eficiencia y otros aspectos haciendo uso del sistema. En el impacto social, tecnológico y ambiental el impacto será alta, mientras tanto en el aspecto económico no habrá impacto por la inversión inicial, pero un futuro resultará beneficioso esa inversión.

6 CONCLUSIONES 

Con el desarrollo de este sistema se automatizan los procesos de pago de horas extras, puesto que arrojan el valor monetario que se le debe abonar al trabajador, para que el departamento financiero efectué el depósito correspondiente.



Con la metodología (SCRUM) seleccionada para el desarrollo de este software se obtuvieron resultados en muy poco tiempo, debido a que esta metodología es ágil y lo que busca es entregar funcionalidades de manera temprana.



El uso de un framework de desarrollo facilita mucha las cosas debido a que la gran mayoría de validaciones ya están realizadas dentro del mismo, por lo que ahorra mucho tiempo para realizar validaciones. Además, Laravel que fue el framework utilizado es el más versátil en cuanto a un diseño adaptativo a cualquier dispositivo, con esto se puede considerar al sistema como un aplicativo móvil no nativo.

7 RECOMENDACIONES 

Una recomendación muy importante es tener muy claros los objetivos que se quieren alcanzar con la realización de un sistema, debido a que puede costar mucho tiempo de desarrollo el no haber prestado atención a la planificación del proyecto y su alcance.



En la etapa de ejecución del proyecto se debe tener una idea clara de las bases de sistema, es decir de la Base de Datos ya que este es el primer pilar del desarrollo, si no se diseña una base de datos de manera adecuada a cada sistema significara un retraso importante para la entrega del producto.



Las herramientas de las que se vaya a ser uso dentro del desarrollo deben ser confiables, intuitivas y con documentación. Porque una herramienta que es capaz de mostrar guías al programador harán que varios algoritmos, sentencias, conexiones, etc, puedan ser tomadas de la documentación para la aplicación en el sistema que se esté realizando.



La comunicación en la realización de un proyecto es muy importante, tanto cliente como el equipo de desarrollo tendrán control sobre el sistema, ofreciendo las ideas de cómo se podrá realizar una meta en específico, por eso el uso de Scrum fue de gran apoyo.

8 REFERENCIAS A hackable text editor for the 21st Century. (2017). Atom. Recuperado 3 noviembre 2017, de https://atom.io/ Alvarez García, A., Heras del Dedo, R., & Gómez, C. (2012). Manual imprescindible de Métodos ágiles y Scrum. Madrid, España: Anaya Multimedia. Chiavenato, I. (2011). Administración de recursos humanos. Mexico: McGraw-Hill. Clemente Bonilla, P. (2014). Diseño web adaptativo. Madrid: Anaya Multimedia. Cobo, A., Gómez, P., Pérez, D., & Rocha, R. (2008). PHP y MySQL. Madrid: Díaz de Santos. Coronel, C., Morris, S., & Peter, Rob. (2011). Base de Datos Diseñǫ, implementación̤ y administración̤. México: Cengage Learning. Deitel, H., & Deitel, P. (2012). Cómo programar en Java. México: Pearson Educación. García, J. (11 febrero 2018). ¿Qué es Laravel? - Blog de arsys.es. Recuperado de https://www.arsys.es/blog/programacion/que-es-laravel/ Haughee, E. (2013). Instant Sublime Text Starter. Inglaterra: Packt Publishing. Herrera Ríos, E. (2013). Arrancar con HTML5 curso de programación. México: Alfaomega. Instituto Nacional de Estadísticas y Censos. (2014). Empresas y Tic’s. Recuperado de: http://www.ecuadorencifras.gob.ec/documentos/web-inec/ Kappel, G., Pröll, B., Reich, S., & Retschitzegger, W. (2011). Web engineering. Heidelberg: Dpunkt-Verlag. Méndez Morales, J. (2012). La Economía en la Empresa en la Sociedad del Conocimiento (4a ed.). México: McGraw-Hill. Ministerio del Trabajo (2013). Código de Trabajo. Recuperado de http://www.trabajo.gob.ec Mondy, R., & Mondy, J. (2010). Administración de recursos humanos. México: Pearson Educación de México.

81 MySQL. (2017). Acerca de MySQL. Recuperado el 26 de octubre de 2018, de http://mysql.com/about/. Orós Cabello, J. (2013). Guía práctica de XHTML, JavaScript y CSS. México: Alfaomega. Pfleeger Lawrence, S. (2002). Ingeniería de software teoría y práctica. Buenos Aires, Argentina: Pearson Education. Piñero Gómez, J. (2013). Bases de datos relacionales y modelado de datos. Madrid, España: Paraninfo. PostgreSQL. (2017). Acerca de PostgreSQL. Recuperado el 30 octubre de 2017, de https://www.postgresql.org/about/ Pressman, R. (2010). Ingeniería del software un enfoque práctico. México: McGraw-Hill. Reinosa, E., Maldonado, C., Muñoz, R., Damiano, L., & Abrutsky, M. (2012). Bases de datos. Argentina: Alfaomega Grupo Editor. Rubiales Gómez, M. (2013). HTML5, CSS3 y Javascript. Madrid, España: Anaya Multimedia-Anaya Interactiva. Rubio, M. (2018). ¿Qué es Diseño Adaptativo? Joomla! Community Magazine. Recuperado 17

abril

2018,

https://magazine.joomla.org/es/ediciones-anteriores/sept-

2013/item/1514-que-es-diseno-adaptativo Schildt, H. (2011). Fundamentos de Java. México: McGraw-Hill. Secretaria Nacional de Planificación y Desarrollo (2017). Plan Nacional del Buen Vivir (2013-2017). Recuperado de http://www.buenvivir.gob.ec Sistemas Web: KnowDo. (2018). Knowdo.org. Recuperado 3 noviembre 2017, de http://www.knowdo.org/knowledge/39-sistemas-web Sommerville, I. (2011). Ingeniería de software. México: Pearson Educación de México. Valderrey Sanz, P. (2013). Administración̤ de sistemas gestores de bases de datos. Colombia, Bogotá: Ecoe Ediciones.

82 Vaswani, V. (2010). Fundamentos de PHP. México: McGraw-Hill. Webster, L. (2017). IDE de Visual Studio. Visual Studio. Recuperado 3 noviembre 2017, de https://www.visualstudio.com/es/vs/ Zofío Jiménez, J. Aplicaciones web. Madrid, España: MACMILLAN IBERIA.

9 GLOSARIO SOFTWARE: Es una herramienta digital que se encuentran en los dispositivos tecnológicos, como sistemas operativos, programas y aplicaciones que tiene como objetivo facilitar las tareas. SMARTH-PHONE: Teléfono inteligente, suelen ser dispositivos con acceso a internet, además de tener características tecnológicas actuales. FRONT-END: El front-end se refiere a la parte del software que va enfocada al Usuario, es decir lo que el Usuario visualiza y su experiencia con ello. BACK-END: Es aquellos que el Usuario no visualiza del software, es decir la codificación, las conexiones necesarias, algoritmos usados etc. Estos hacen que el software sea funcional. TICS: Tecnologías de la información y comunicación. REGLAS DE ORO: Son las normas que se orientan a un buen diseño visual del software o Sistema. COMMON LANGUAGE RUNTIME: Es el encargado de ejecutar el código en plataformas de Microsoft. UML: Unified Modeling Language es un modelado do software que son muy usados en el desarrollo, existentes varios tipos, de secuencia, de actividades, de clase, de objetos, etc. OPEN SOURCE: Es una licencia de software de código abierto, es decir que el propietario del software permite modificar el software para cualquier fin, sin ningún costo

10 ANEXOS Anexo 1. Carta de Aceptaciรณn del Proyecto

85 Anexo 2. Carta de Impacto

Anexo 3. Acta de Entrega

87 Anexo 4. Historias de Usuario Número: 1

Usuario: Usuario/Administrador

Nombre historia: Interfaz de Login Prioridad en negocio: 9

Riesgo en desarrollo: Media

Puntos estimados: 13

Iteración asignada: 1

Programador responsable: Luis Fernando Arequipa Descripción: COMO usuario QUIERO una Interfaz de login PARA acceder al sistema Observaciones: DADO la interfaz de Login CUANDO ingrese mi usuario y contraseña; y de click sobre ingresar ENTONCES se muestren los formularios del sistema. DADO la interfaz de Login CUANDO ingrese mi usuario y contraseña y seleccione ingresar ENTONCES aparezca el módulo de conteo de horas trabajadas. DADO la interfaz de Login CUANDO ingrese mi usuario y contraseña erróneos; y de click sobre ingresar ENTONCES me notifique no que puedo acceder por campos inválidos.

88 Historia de Usuario Número: 2

Usuario: Administrador

Nombre historia: Creación de Módulos Prioridad en negocio: 8

Riesgo en desarrollo: Alta

Puntos estimados: 20

Iteración asignada: 1

Programador responsable: Luis Fernando Arequipa Descripción: COMO administrador QUIERO varios módulos PARA registrar nuevos departamentos, áreas o cargos que surjan en algún futuro. Observaciones: DADO cada módulo CUANDO de click sobre alguno de ellos ENTONCES se desplieguen dos pestañas de listado y de registro. DADO cada módulo CUANDO de click sobre la pestaña registro ENTONCES se muestre los campos en blanco para agregar más campos a ese módulo DADO cada módulo CUANDO de click sobre la pestaña listado ENTONCES aparezca todos los campos que se han creado en cada uno de los módulos. DADO cada módulo CUANDO quiera añadir un nuevo campo y no haya llenado todos los datos; al hacer click en guardar ENTONCES se muestre un mensaje de advertencia.

89 Historia de Usuario Número: 3

Usuario: Empleado

Nombre historia: Registro de Conteo de horas trabajadas Prioridad en negocio: 9

Riesgo en desarrollo: Alta

Puntos estimados: 20

Iteración asignada: 1

Programador responsable: Bryan Gonzalo Meza Descripción: COMO empleado QUIERO un módulo de conteo de horas trabajadas PARA registrar mi trabajo. Observaciones: DADO el registro de conteo de horas trabajadas CUANDO de click sobre el módulo ENTONCES empiece a correr el tiempo del trabajo. DADO el registra de conteo de horas trabajadas CUANDO de click sobre el finalizar ENTONCES me muestre el número de horas trabajadas DADO el registra de conteo de horas trabajadas CUANDO de click sobre el módulo ENTONCES aparezca una caja de texto para detallar el trabajo.

90 Historia de Usuario Número: 4

Usuario: Administrador

Nombre historia: Funcionalidad de editar y eliminar Prioridad en negocio: 21

Riesgo en desarrollo: Bajo

Puntos estimados: 5

Iteración asignada: 2

Programador responsable: Bryan Gonzalo Meza Descripción: COMO administrador QUIERO la funcionalidad de editar y eliminar PARA dar de baja a un empleado o corregir un campo. Observaciones: DADO la funcionalidad de editar y eliminar CUANDO seleccione el empleado y de click sobre eliminar ENTONCES lo elimine y aparezca la notificación eliminado. DADO la funcionalidad de editar y eliminar CUANDO de click sobre eliminar ENTONCES el sistema me lo pregunte de nuevo para eliminar algún campo. DADO la funcionalidad de editar y eliminar CUANDO de click sobre editar ENTONCES el sistema guardara los campos que anteriormente tenía ingresados, permitiendo así no escribir todo de nuevo. DADO la funcionalidad de editar y eliminar CUANDO de click sobre editar ENTONCES el sistema muestre un nuevo botón para guardar la edición. DADO la funcionalidad de editar y eliminar CUANDO falten campos de editar de click sobre guardar ENTONCES el sistema muestre un mensaje de advertencia y no guarde la edición.

91 Historia de Usuario Número: 5

Usuario: Empleado

Nombre historia: Creación de Formularios Prioridad en negocio: 20

Riesgo en desarrollo: Alta

Puntos estimados: 40

Iteración asignada: 2

Programador responsable: Luis Fernando Arequipa Descripción: COMO administrador QUIERO ingresar detalladamente la programación de las diferentes tipos de horas del área técnica/comercial PARA llevar un control minucioso de las actividades realizadas por el personal Observaciones: DADO el ingreso de datos esté incompletos en el formulario CUANDO de click en guardar ENTONCES me salga una advertencia de complete todos los campos. DADO el registro en el formulario sea incorrecto CUANDO de click sobre el eliminar ENTONCES eliminara el registro seleccionado. DADO el registro en el formulario sea incorrecto CUANDO de click sobre el campo erróneo ENTONCES me permita editar dicho campo DADO el ingreso de campos específicos para cálculo de hora extra en el formulario CUANDO sean ingresados los datos requeridos ENTONCES me calcule automáticamente el monto respectivo.

92 Historia de Usuario Número: 6

Usuario: Jefe de Área/Administrador

Nombre historia: Generación de Reportes Prioridad en negocio: 7

Riesgo en desarrollo: Media

Puntos estimados: 13

Iteración asignada: 3

Programador responsable: Bryan Gonzalo Meza Descripción: COMO administrador QUIERO generar reportes PARA tener un respaldo físico de lo que se ha trabajado. Observaciones: DADO la generación de reportes CUANDO de click sobre el formato de generación (PDF o xlsm) ENTONCES se descargue el formulario en el formato escogido. DADO la generación de reportes CUANDO de click sobre el formato de generación (PDF o xlsm) ENTONCES me pregunte en que carpeta deseo guardar el documento.

93 Historia de Usuario Número: 7

Usuario: Jefe de Área/Administrador

Nombre historia: Caja de Búsqueda Rápida Prioridad en negocio: 7

Riesgo en desarrollo: Media

Puntos estimados: 13

Iteración asignada: 3

Programador responsable: Bryan Gonzalo Meza Descripción: COMO administrador QUIERO una caja de búsqueda rápida PARA así encontrar de una manera más fácil la información requerida. Observaciones: DADO la caja de búsqueda rápida CUANDO introduzca una letra sobre la caja de texto ENTONCES aparezcan las palabras que contengan esa letra. DADO la caja de búsqueda rápida CUANDO introduzca una consonante y vocal sobre la caja de texto ENTONCES las palabras que contengan dichas letras. DADO la caja de búsqueda rápida CUANDO introduzca unas letras sobre la caja de texto que no existan en el sistema ENTONCES el sistema no arroje ningún dato.

94 Anexo 5. Pruebas de Aceptación Prueba de Aceptación 1 Código: 001 Nombre caso de prueba: Ingreso al Sistema Historia de usuario asociada: 2, 3, 4, 5, 6 y 7 Descripción: En esta sección el usuario ya se empleado o administrador, puede ingresar a visualizar y usar el sistema. Pre-condiciones  El usuario debe contar con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El usuario debe ingresar al sistema  El administrador puede visualizar todos los módulos del sistema Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: el usuario ingresa al sistema Modulo/sección a evaluar. Interfaz de Login

Prueba de Aceptación 2 Código: 002 Nombre caso de prueba: Módulos del Sistema Modulo/sección a evaluar. Todos los módulos, excepto el Historia de usuario asociada: 2 de cálculo. 3, 4, 5 y 6 Descripción: En esta sección el administrador tiene acceso a los módulos, para registrar o visualizar el listado. Pre-condiciones  El usuario debió ingresar al sistema con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El administrador puede ingresar nuevos campos en cada módulo.  El administrador puede visualizar todos los registros creados y existentes del sistema. Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: El administrador agrega áreas, departamentos, cargos nuevos al sistema

95 Prueba de Aceptación 3 Código: 003 Nombre caso de prueba: Conteo de Horas Trabajadas Modulo/sección a evaluar. Registro de conteo de horas Historia de usuario asociada: 5 trabajadas. y6 Descripción: En esta sección el empleado tiene únicamente acceso a este módulo para contabilizar el trabajo realizado. Pre-condiciones  El usuario debió ingresar al sistema con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El usuario puede saber la hora que inició y terminó el trabajo.  El usuario podrá consultar el número de horas que ha realizado. Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: El usuario conocerá cual es el trabajo extra que realizo en 15 días.

Prueba de Aceptación 4 Código: 004 Nombre caso de prueba: Funcionalidad de editar y eliminar Modulo/sección a evaluar. Todos los módulos, excepto el Historia de usuario asociada: de cálculo. 2, 4, 5, 6 y 7 Descripción: En esta sección el administrador puede configurar cualquier registro que el crea pertinente, así también como el de eliminarlo. Pre-condiciones  El usuario debió ingresar al sistema con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El administrador puede ingresar nuevos campos en cada módulo.  El administrador puede visualizar todos los registros creados y existentes del sistema. Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: El administrador agrega áreas, departamentos, cargos nuevos al sistema

96 Prueba de Aceptación 5 Código: 005 Nombre caso de prueba: Creación de los Formularios Historia de usuario asociada: 3, 4, 5, 6 y 7 Descripción: En esta sección el administrador tiene acceso a seis formularios estándares de la empresa para el pago de horas extras. Pre-condiciones  El usuario debió ingresar al sistema con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El administrador puede visualizar un cada formulario que refleja el pago a cada empleado  El administrador puede editar o eliminar algún campo que resulte erróneo conforme a la planificación. Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: El administrador enviara el informe a financiero para que se realice el pago Modulo/sección a evaluar. Módulo de ATH

Prueba de Aceptación 7 Código: 007 Nombre caso de prueba: Caja de Búsqueda rápida Modulo/sección a evaluar. Todos los módulos, excepto el Historia de usuario asociada: 2 de cálculo. 4, 5, 6 y 7 Descripción: En esta sección el administrador tiene acceso a buscar en todos los módulos los campos que necesite. Pre-condiciones  El usuario debió ingresar al sistema con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El administrador puede filtrar los resultados de la búsqueda.  El administrador puede todos los campos donde aparezca la palabra que ingreso. Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: El administrador encontrara la información de manera eficiente.

97 Prueba de Aceptación 6 Código: 006 Nombre caso de prueba: Generación de Reportes Modulo/sección a evaluar. Todos los módulos, excepto el Historia de usuario asociada: 2 de cálculo. 3, 4, 5, 6 y 7 Descripción: En esta sección el administrador tiene acceso a los módulos, para registrar o visualizar el listado. Pre-condiciones  El usuario debió ingresar al sistema con un usuario y contraseña. Pasos y condiciones de ejecución  El usuario necesita acceso a internet. Resultado esperado  El administrador puede descargar archivos en formato PDF y xlsx.  El administrador puede obtener los reportes solamente de los formularios ATH. Éxito Fallo Estado de prueba Si No Errores asociados: Ninguno Acción final: El administrador genera reportes en dos tipos de formatos

98 Anexo 6. Diccionario de datos Áreas Columna id (Primaria) nombre estatus created_at updated_at Índices

Tipo int(10) varchar(170) tinyint(1) timestamp timestamp

Nombre de la clave PRIMARY areas_nombre_unique

Tipo BTREE BTREE

Nulo No No No Sí Sí

Único Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Comentario

Cargos Columna id (Primaria) nombre estatus created_at updated_at

Tipo int(10) varchar(170) tinyint(1) timestamp timestamp

Nulo No No No Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Índices Nombre de la clave PRIMARY cargos_nombre_unique

Tipo BTREE BTREE

Único Sí Sí

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Comentario

Departamentos Columna id (Primaria) nombre estatus created_at updated_at

Tipo int(10) varchar(170) tinyint(1) timestamp timestamp

Nulo No No No Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Índices Nombre de la clave PRIMARY departamentos_nombre_unique

Tipo BTREE BTREE

Único Sí Sí

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Empleados Columna id (Primaria) documento codigo nombre apellido direccion rmu fecha_ingreso cert_presupuestaria created_at updated_at

Tipo int(10) varchar(255) varchar(255) varchar(255) varchar(255) varchar(255) double(8,2) date varchar(255) timestamp timestamp

Nulo No No No No No Sí No No Sí Sí Sí

Predeterminado

NULL

NULL NULL NULL

Comentarios

Comentario

99 areas_id (Primaria) cargos_id (Primaria) leyes_id (Primaria) etapas_id (Primaria) nominas_id (Primaria) departamentos_id (Primaria)

int(10) int(10) int(10) int(10) int(10) int(10)

No No No No No No

Índices Nombre de la clave

Tipo

Único

Empaquetado

PRIMARY

BTREE

Sí

fk_empleados_areas1_idx fk_empleados_cargos1_idx fk_empleados_leyes1_idx fk_empleados_etapas1_idx fk_empleados_nominas1_idx fk_empleados_departamentos1_idx

BTREE BTREE BTREE BTREE BTREE BTREE

No No No No No No

Columna id areas_id cargos_id leyes_id etapas_id nominas_id departamentos_id areas_id cargos_id leyes_id etapas_id nominas_id departamentos_id

Cardinalidad 0 0 0 0 0 0 0 0 0 0 0 0 0

Cotejamiento A A A A A A A A A A A A A

Nulo No No No No No No No No No No No No No

Comentario

Etapas

Columna id (Primaria) nombre estatus created_at updated_at Índices

Tipo int(10) varchar(170) tinyint(1) timestamp timestamp

Nombre de la clave PRIMARY etapas_nombre_unique

Tipo BTREE BTREE

Nulo No No No Sí Sí

Único Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Feriados

Columna id (Primaria) nombre fecha created_at updated_at

Tipo int(10) varchar(255) date timestamp timestamp

Nulo No No No Sí Sí

Predeterminado

Comentarios

NULL NULL

Índices Nombre de la clave PRIMARY

Tipo BTREE

Único Sí

Empaquetado No

Columna id

Cardinalidad 0

Cotejamiento A

Hora_laboradas Columna fecha hora_inicio hora_fin empleado_rmu justificacion estatus created_at

Tipo date varchar(255) varchar(255) double(8,2) varchar(255) int(11) timestamp

Nulo No No No No No No Sí

Predeterminado

0 NULL

Comentarios

Nulo No

Comentario

100 updated_at empleado_id tarifas_id empleados_id

timestamp int(10) int(10) int(10)

Sí No No No

NULL

Único No No

Empaquetado No No

Índices Nombre de la clave fk_hora_laboradas_tarifas1_idx fk_hora_laboradas_empleados1_idx

Tipo BTREE BTREE

Columna tarifas_id empleados_id

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Comentario

Leyes

Columna id (Primaria) nombre estatus created_at updated_at

Tipo int(10) varchar(170) tinyint(1) timestamp timestamp

Nulo No No No Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Índices Nombre de la clave PRIMARY leyes_nombre_unique

Tipo BTREE BTREE

Único Sí Sí

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Comentario

Migrations Columna id (Primaria) migration batch Índices

Tipo int(10) varchar(255) int(11)

Nombre de la clave PRIMARY

Tipo BTREE

Nulo No No No

Único Sí

Predeterminado

Empaquetado No

Comentarios

Columna id

Cardinalidad 0

Cotejamiento A

Nulo No

Comentario

Nominas Columna id (Primaria) nombre estatus created_at updated_at

Tipo int(10) varchar(170) tinyint(1) timestamp timestamp

Nulo No No No Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Índices Nombre de la clave PRIMARY nominas_nombre_unique

Tipo BTREE BTREE

Único Sí Sí

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Password_resets Columna username token created_at

Tipo varchar(70) varchar(255) timestamp

Nulo No No Sí

Predeterminado

NULL

Comentarios

Cotejamiento A A

Nulo No No

Comentario

101 Índices Nombre de la clave password_resets_username_index

Tipo BTREE

Único No

Empaquetado No

Columna username

Cardinalidad 0

Cotejamiento A

Nulo No

Comentario

Tarifas Columna id (Primaria) nombre valor estatus created_at updated_at

Tipo int(10) varchar(170) int(11) tinyint(1) timestamp timestamp

Nulo No No No No Sí Sí

Predeterminado

Comentarios

0 NULL NULL

Índices Nombre de la clave PRIMARY tarifas_nombre_unique

Tipo BTREE BTREE

Único Sí Sí

Empaquetado No No

Columna id nombre

Cardinalidad 0 0

Cotejamiento A A

Nulo No No

Comentario

Cotejamiento A A A

Nulo No No No

Comentario

Users Columna id (Primaria) nombre apellido username email password remember_token created_at updated_at role_id estatus empleado_id temporal_clave

Tipo int(10) varchar(170) varchar(170) varchar(70) varchar(150) varchar(255) varchar(100) timestamp timestamp int(10) int(10) int(10) tinyint(1)

Nulo No No No No No No Sí Sí Sí No No Sí Sí

Predeterminado

Comentarios

NULL NULL NULL

NULL NULL

Índices Nombre de la clave PRIMARY users_username_unique users_email_unique

Tipo BTREE BTREE BTREE

Único Sí Sí Sí

Empaquetado No No No

Columna id username email

Cardinalidad 0 0 0

102 Anexo 7. Presupuesto