UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA CARRERA DE INGENIERÍA INFORMÁTICA

Transcripción

1 UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA CARRERA DE INGENIERÍA INFORMÁTICA REINGENIERÍA DEL SISTEMA ERP SOCIAL E IMPLEMENTACIÓN EN LA ESCUELA DE LA UNIDAD EDUCATIVA CORAZON DE MARÍA PARROQUIA TUMBACO DEL DISTRITO METROPOLITANO DE QUITO. TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO INFORMÁTICO AUTOR: Tovar Campaña José Ignacio. TUTOR: Ing. César Agusto Morales Mejía MSC. QUITO-ECUADOR 2015

2 DEDICATORIA A dios en primer lugar, segundo y la más importante a mis padres, a mi madre Silvana por tantas noches de desvelo y por mantenerse siempre a mi lado y nunca dejarme rendirme durante todas las etapas de la vida, a mi padre Tarquino al que no pude darle la alegría de verme graduado pero sé que es mi ángel en el cielo y desde ahí estará orgulloso de su hijo, ya que con su ejemplo y enseñanzas dedico su vida a nosotros, desde aquí un gracias padre mío. A mi esposa quien estuvo siempre a mi lado impulsándome y dándome fuerzas para seguir. A mi hija que es el motor de mi vida por la que seguiré luchando siempre. A toda mi familia por acompañarme siempre. José Ignacio Tovar Campaña II

3 AGRADECIMIENTO A los docentes por brindarnos a los estudiantes durante el proceso de formación el conocimiento y las herramientas necesarias para un excelente desempeño profesional ético. A mi Tutor Ing. César Morales, director de tesis, por su valiosa orientación en todo momento, durante el desarrollo y culminación del proyecto de tesis. A la prestigiosa Universidad Central del Ecuador, Facultad de Ingeniería, Ciencias y Matemática por haberme dado la oportunidad de formarme como profesional. José Ignacio Tovar Campaña III

4 AUTORIZACIÓN DE AUTORÍA INTELECTUAL Yo, José Ignacio Tovar Campaña en calidad de autor del trabajo de investigación o tesis realizada sobre REINGENIERÍA DEL SISTEMA ERP SOCIAL E IMPLEMENTACIÓN EN LA ESCUELA DE LA UNIDAD EDUCATIVA CORAZON DE MARÍA, por el presente autorizo a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de todos los contenidos que me pertenecen o de parte de los que contiene esta obra, con fines estrictamente académicos o de investigación. Los derechos que como autor me corresponden, con excepción de la presente autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los artículos 5, 6, 8, 19 y demás participantes de la Ley de Propiedad Intelectual y su reglamento. 13 de mayo de 2015 José Ignacio Tovar Campaña. CI: IV

5 CERTIFICACION DEL TUTOR V

6 NOTIFICACIÓN DE TRIBUNAL VI

7 RESULTADO DEL TRABAJO DE GRADUACIÓN VII

8 CONTENIDO DEDICATORIA II AGRADECIMIENTO III AUTORIZACIÓN DE AUTORÍA INTELECTUAL IV CERTIFICACION DEL TUTOR V NOTIFICACIÓN DE TRIBUNAL VI RESULTADO DEL TRABAJO DE GRADUACIÓN VII CONTENIDO VIII LISTA DE FIGURAS X LISTA DE TABLAS XI RESUMEN XII ABSTRACT XIII CERTIFICADO DE TRADUCCIÓN XIV TÍTULO XV INTRODUCCIÓN 1 CAPITULO I 2 1. PRESENTACIÓN DEL PROBLEMA Planteamiento del Problema Formulación del Problema Interrogantes de la Investigación Objetivo de la Investigación Objetivo General Objetivos Específicos Justificación Alcance Limitaciones 7 CAPITULO II 8 2. REVISIÓN BIBLIOGRÁFICA Antecedentes Marco Teórico Beneficios del ERP Limitaciones Análisis y diseño Implementación Seguimiento Evaluación Control Modelo de Desarrollo Metodología Lenguaje de programación java 15 VIII

9 Base de Datos Identificación de Variables Variables Independientes Variables Dependientes Hipótesis 23 CAPÍTULO III METODOLOGÍA Metodología RUP Principales características Ciclo de Vida Fases del ciclo de vida del RUP Principios clave Ventajas Desventajas Requerimientos Requerimientos no funcionales Requerimientos funcionales Requerimientos Técnicos Lenguaje de Modelamiento Unificado (UML) Funciones de UML Diagramas UML Arquitectura Modelo-Vista-Controlador Diseño de la Base de Datos Estudio Previo Estándares de la Base de Datos Creación de la Base de Datos Diccionario de Datos 61 CAPÍTULO IV MARCO ADMINISTRATIVO Recursos Recursos Institucionales Recursos del autor Costos 64 CAPITULO V Conclusiones y Recomendaciones Conclusiones Recomendaciones 66 GLOSARIO 67 REFERENCIAS BIBLIOGRÁFICAS 71 ANEXO I 73 ANEXO II 77 IX

10 MANUAL DE USUARIO 77 Pantalla inicial 78 Cabecera 79 Menú 80 Menú Control de Asistencia 81 Reporte de horas Trabajadas 82 Reporte de Faltas 84 Reporte de Atrasos 85 Definición de día Laboral 86 Registro de Permisos 87 Definición de tipos de horarios 88 Parámetros de Ingreso 89 Registro manual de Faltas 90 Registro de nuevo empleado 91 Definición de horarios 94 LISTA DE FIGURAS FIGURA 1. MODELO EN V. 12 FIGURA 2. MODELO DE DESARROLLO. 13 FIGURA 3. TRIÁNGULO DE GESTIÓN DE PROYECTOS. 21 FIGURA 4. PIRÁMIDE DE LA CALIDAD. 22 FIGURA 5. CICLO DE VIDA RUP. 26 FIGURA 6. DIAGRAMA DE CLASES. 41 FIGURA 7. CLASE. 41 FIGURA 8. ASOCIACIÓN GENERALIZACIÓN. 42 FIGURA 9. ASOCIACIÓN FIGURA 10. ASOCIACIÓN ACUMULACIÓN. 44 FIGURA 11. ASOCIACIÓN COMPOSICIÓN. 44 FIGURA 12. CASOS DE USO. 45 FIGURA 13. DEFINICIÓN PERSONA-EMPLEADO. 46 FIGURA 14. DEFINICIÓN HORARIO. 48 FIGURA 15. CASO DE USO FIGURA 16. CASO DE USO FIGURA 17. CASO DE USO FIGURA 18. DIAGRAMA DE SECUENCIA. 53 FIGURA 19. DIAGRAMA DE SECUENCIA AUTENTICACIÓN. 54 FIGURA 20. DIAGRAMA DE SECUENCIA ADMINISTRACIÓN. 55 FIGURA 21. DIAGRAMA DE ACTIVIDADES. 55 FIGURA 22. CICLO DE VIDA DE MVC. 57 X

11 LISTA DE TABLAS CUADRO 1. REQUERIMIENTO NO FUNCIONAL 30 CUADRO 2. REQUERIMIENTO FUNCIONAL CUADRO 3. REQUERIMIENTO FUNCIONAL CUADRO 4. REQUERIMIENTO FUNCIONAL CUADRO 5. REQUERIMIENTO FUNCIONAL CUADRO 6. REQUERIMIENTO FUNCIONAL CUADRO 7. REQUERIMIENTO FUNCIONAL CUADRO 8. REQUERIMIENTO FUNCIONAL CUADRO 9. REQUERIMIENTOS TÉCNICOS SERVIDOR. 38 CUADRO 10. MÉTODO INGRESAEMPLEADO. 46 CUADRO 11. MÉTODO CONSULTAEMPLEADO. 47 CUADRO 12. MÉTODO ACTUALIZAEMPLEADO. 47 CUADRO 13. MÉTODO INGRESARCODIGO. 48 CUADRO 14. ACTORES. 50 CUADRO 15. ESPECIFICACIÓN CASO DE USO REGISTRAR EMPLEADO. 52 CUADRO 16. PREFIJOS BDD. 58 CUADRO 17. SUFIJOS BDD. 58 CUADRO 18. RECURSOS. 62 CUADRO 19. COSTOS. 64 XI

12 RESUMEN REINGENIERÍA DEL SISTEMA ERP SOCIAL E IMPLEMENTACIÓN EN LA ESCUELA DE LA UNIDAD EDUCATIVA CORAZON DE MARÍA El objetivo de proyecto ErpSocial, es continuar con la iniciativa de la Facultad de Ingeniería Ciencias Físicas y Matemática de la Universidad Central de Ecuador en brindar a la sociedad herramientas Informáticas que permitas a las diferentes instituciones mejorar y automatizar sus proceso, además de formar el hábito de colaboración de los estudiantes para con la sociedad. El sistema está diseñado de una manera que sea amigable con los usuarios además de brindar beneficios y mejoras a los procesos que actualmente se mantienen en las instituciones. Gracias a su versatilidad, fortaleza y potencia el sistema ERP (Enterprise Resource Planning) puede adaptarse a cualquier institución que maneje la misma lógica de negocio. Durante la etapa de análisis se eligió las mejores herramientas para ejecutar la reingeniería del sistema ErpSocial en su versión JAVA-Web la cual podrá ser accedida mediante cualquier dispositivo conectado a una red de internet. DESCRIPTORES: ERP: ENTERPRISE RESOURCE PLANNING/ ERP- SOCIAL/ VINCULACIÓN CON LA SOCIEDAD/ SISTEMA WEB/REINGENIERÍA DEL SISTEMA XII

13 ABSTRACT The aim of ErpSocial project is to continue the initiative of the Faculty of Physical Sciences and Mathematics Engineering of the Central University of Ecuador in providing society with tools that allow different institutions to improve and automate their process, and forming the habit collaboration of students towards society. The system is designed in a way that is friendly to users in addition to providing benefits and improvements to processes that are currently held in institutions. Thanks to their versatility, strength and power the ERP system (Enterprise Resource Planning) can be adapted to any institution that handles the same business logic. During the analysis stage it was chosen the best tools to implement reengineering ErpSocial system as a JAVA-Web version which can be accessed by any device connected to an internet network. DESCRIPTORS: ERP: ENTERPRISE RESOURCE PLANNING/ ERP- SOCIAL/ VINCULACIÓN CON LA SOCIEDAD/ SISTEMA WEB/REINGENIERÍA DEL SISTEMA XIII

14 CERTIFICADO DE TRADUCCIÓN XIV

15 TÍTULO XV

16 INTRODUCCIÓN En el transcurrir del tiempo la utilización de tecnología se ha hecho preponderante en todo tipo de actividades, las aplicaciones informáticas son parte del diario vivir y los servicios que estas prestan forman parte importante de la vida social. Son innumerables las actividades que dependen netamente de los medios informáticos. En la sociedad actual es necesario contar con sistemas informáticos que se diversifiquen y permitan realizar varias operaciones sobre los mismos, estos servicios son conocidos como tecnologías de la información. Los sistemas ERP por sus siglas en ingles ENTERPRISE RESOURCE PLANNING, son los que mayor avance tienen hoy en día ya que permiten mantener información de varios sistemas integrados en una sola plataforma, esto mejora la visión global de todo un proceso y permite optimizar los procesos de negocio. La Facultad de Ingeniería, Ciencias Físicas y Matemática, de la Universidad Central del Ecuador, en vista de promover la automatización de procesos y vinculación con la sociedad ha implementado en la parroquia San Pedro de Amaguaña, del Distrito Metropolitano de Quito, el sistema ERP Social, que administra los módulos relacionados a la gestión documental escolar y eclesiástica. 1

17 CAPITULO I 1. PRESENTACIÓN DEL PROBLEMA 1.1. Planteamiento del Problema La Facultad de Ingeniería de la Universidad Central del Ecuador, institución de alta excelencia académica y social, durante su trayectoria ha promovido el desarrollo del país, formando profesionales comprometidos al servicio de los intereses del bienestar del pueblo ecuatoriano y el mundo. [2] Hoy en día la automatización de los procesos que se ejecutan en una organización está basada en la implementación de sistemas informáticos, es así, que se plantea como proyecto la Implementación del Sistema ERP Social, en la Escuela de la Unidad Educativa Corazón de Maria del cantón Quito, provincia de Pichincha y reingeniería del sistema a nuevas herramientas de desarrollo. El objetivo del proyecto es la reingeniería del sistema actual a nuevas herramientas de desarrollo y brindar a la Escuela de la Unidad Educativa Corazón de Maria, automatizar los procesos de control de asistencia de sus empleados. Como antecedentes para el presente proyecto se tiene que el proyecto ERP Social, fue implementado en la parroquia de Amaguaña de la provincia de Pichincha. La reingeniería del sistema actual está basada en la constante evolución de los sistemas informáticos, tanto en sus tecnologías como en herramientas de desarrollo, es preciso mejorar aspectos como robustez, calidad y eficiencia, para cumplir con las demandas de los usuarios y de los procesos de trabajo en sí. 2

18 1.2. Formulación del Problema La Escuela de la Unidad Educativa Corazón de Maria de la parroquia Tumbaco del Cantón Quito de la provincia de Pichincha, se encuentran desprovistas de sistemas que les permita manejar correctamente los procesos de la gestión de asistencia de sus empleados; por lo cual los procesos se lo realizan de forma manual, lo que consume tiempo y recursos innecesarios que pueden ser optimizados dentro de la cada Institución. Previo el planteamiento del proyecto se realizó un análisis en base a visitas y entrevistas para identificar las necesidades de las instituciones. De los resultados obtenidos se plantea la implementación del Módulo de Control de Asistencia del sistema ERP Social, planteando así el levantamiento y mejora de los procesos que realizan referentes al control de asistencia en base a sus recursos tanto físicos como económicos lo cual permitirá que el sistema se ajuste de manera exitosa a futuro en diferentes parroquias, con una mayor efectividad en el manejo del flujo y procesamiento de los datos y contribuirá al mejoramiento progresivo de la comunidad y la sociedad. La reingeniería e implementación del sistema ERP Social Modulo de Control de Asistencia tiene como objetivo brindar a las instituciones beneficios como: Disminución de uso de suministros de oficina. Mantener información en línea. Automatización de su proceso de control de asistencia. Mejora de los procesos institucionales. 3

19 1.3. Interrogantes de la Investigación En el presente trabajo de graduación se plantea las siguientes interrogantes: Se realiza el control de asistencia de los empleados? El control de asistencia de los empleados de la institución se realiza mediante algún medio informático? Es necesario emitir reportes de asistencia? Es eficiente el método para realizar el control de asistencia que se usa actualmente? La reingeniería del sistema implica cambio de herramientas de desarrollo? El cambio de tecnología para la reingeniería del sistema permitirá realizarlo con herramientas libres? 1.4. Objetivo de la Investigación El principal objetivo del presente proyecto es brindar a las instituciones herramientas informáticas que permitan mejorar sus procesos y realizar de una manera eficiente el control de asistencia de sus empleados, además de retribuir a la sociedad aplicando los conocimientos adquiridos en la Facultad de Ingeniería, Ciencias Físicas Y Matemática, Carrera de Ingeniería Informática de la Universidad Central del Ecuador Objetivo General El objetivo general del presente proyecto es realizar la reingeniería del sistema ErpSocial e implementarlo en La Escuela de la Unidad Educativa Corazón de Maria de la parroquia Tumbaco del Cantón Quito de la provincia de Pichincha realizando el análisis de las falencias que actualmente mantiene la institución para el control de asistencia de su personal, implementado estos requerimientos en la nueva versión del sistema. 4

20 1.6. Objetivos Específicos Para cumplimiento del objetivo general se ha identificado objetivos específicos para el desarrollo del presente proyecto: Realizar el estudio de los procesos que actualmente se manejan en las instituciones para redefinirlas de ser el caso y buscar la mejor estrategia para automatizarlas. Realizar el análisis de los métodos que actualmente se emplean en otras instituciones para el control de asistencia de sus empleados. Optimizar tiempos y recursos para la generación de reportes relacionados con el control de asistencia. Mantener información On line. Realizar el análisis en base a las mejores prácticas de desarrollo para elegir las herramientas para la ejecución del proyecto Justificación La importancia del manejo de la información de una institución es hoy en dia uno de sus principales preocupaciones, es por esto que es necesario la utilización de herramientas informáticas para su adecuado manejo y control. La Escuela de la Unidad Educativa Corazón de Maria no cuenta con un sistema informático de manejo de información referente al control de asistencia, el proceso de control de asistencia se lo realiza de una forma manual esto quiere decir en hojas firmadas, lo cual no es óptimo ni eficiente. Es por esta razón que se propone a La Escuela de la Unidad Educativa Corazón de Maria la solución a este problema con la reingeniería del Sistema ERP-SOCIAL, beneficiando así a la institución y permitiendo que preste un mejor servicio orientado a la comunidad y a sus procesos internos. 5

21 Así, al implantar este sistema poseerá un impacto social positivo, lo cual proporcionará a la institución información ágil, confiable y a la que podrá ser accesada desde cualquier lugar Alcance Implementación del ERP Social, en La Escuela de la Unidad Educativa Corazón de Maria durante su desarrollo se realizará la reingeniería del Sistema ERP Social actual. Previo la implementación del sistema ERP se realizara: Reingeniería del sistema ERP Social V 1.0 Modulo de Control de Asistencia una nueva herramienta de desarrollo basada en lenguaje de programación JAVA. Integración del módulo de Control de Asistencia y Administración de Seguridad del sistema ERP Social para creación de entidades y usuarios. Ejecución de pruebas técnicas y funcionales para validación de estabilidad del sistema. Capacitación a usuarios de La Escuela de la Unidad Educativa Corazón de Maria. Despliegue en producción del sistema ErpSocial Modulo de Control de Asistencia. Los módulos del sistema ERP Social a los que las instituciones tendrán acceso serán: Administración del Sistema: Este módulo se basa en la administración, creación y definición de los perfiles, permisos y asignaciones de los usuarios. Control de Asistencia: Permite tener un control de asistencia de empleados a través de la justificación de faltas, parametrizacion de días no laborables del año y los horarios de entrada y salida. En este módulo también es posible obtener reportes de asistencias, faltas, atrasos. 6

22 1.9. Limitaciones Las posibles limitaciones que pueden restringir sistema a desarrollar son: el desarrollo o uso del No contar con el Hardware necesario para el desarrollo o implementación del sistema. No contar con la disposición y cooperación por parte de los usuarios. No contar con el servicio de Internet. 7

23 2. REVISIÓN BIBLIOGRÁFICA 2.1. Antecedentes CAPITULO II La misión de la Facultad de Ingeniería Ciencias Físicas y Matemática, es crear y difundir el conocimiento científico tecnológico, formar profesionales, investigadores y técnicos críticos de nivel superior y crear espacios para el análisis y solución de los problemas nacionales. [3] Basados en estas premisas fue desarrollado un sistema de gestión para la comunidad y las necesidades que conlleva la planificación y manejo de los organismos principales de las parroquias rurales del cantón Quito, este sistema llamado ERP Social nace de la iniciativa del Director de la Carrera de Ingeniería Informática periodo , de la Escuela de Ciencias Físicas y Matemática de la Ilustre Universidad Central del Ecuador, Ing. Santiago Morales Cardoso, cuyo objetivo principal es brindar el apoyo a la comunidad considerando como materia prima los recursos tecnológicos que se encuentran dentro de las parroquias, este sistema fue implementado en su primera fase en la parroquia de Amaguaña cubriendo las necesidades de la misma. Como evolución y avance del sistema se plantea la expansión de implementación del sistema ERP Social en otras comunidades recogiendo nuevas necesidades y planteando mejoras al sistema ya existente para lo cual se ha definido como nueva comunidad la parroquia de Tumbaco la cual se encuentra al oriente de la ciudad de Quito y cuenta con una población de habitantes aproximadamente. Se realizó la visita a la parroquia y se gestionó una reunión con la Dra. Cecilia Coba presidenta de la junta parroquial a quien se le planteó realizar una presentación general del funcionamiento del sistema, que se planificó para el día lunes 21 de enero del 2013 y conto con la presencia de los directores de escuelas, jardines (educación inicial), iglesia y junta parroquial. 8

24 2.2. Marco Teórico En la Escuela de la Unidad Educativa Corazón de Maria, las instituciones educativas pertenecientes a la parroquia de Tumbaco es importante la implementación del módulo de Control de Asistencia del sistema ERP Social el cual permitirá la regularización y manejo de la información. Un ERP cuya definición es sistema de Planificación de Recursos Empresariales, son Sistemas de Información Gerenciales que integran y manejan negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía en la producción de bienes o servicios. Los sistemas ERP normalmente manejan la producción, logística, distribución, inventario, envíos, facturas y la contabilidad en una organización. Puede intervenir en el control de muchas actividades de negocios como ventas, entregas, pagos, producción, administración de inventarios, calidad de administración y la administración de recursos humanos. Este sistema es un sistema que trata directamente con los clientes, o con los sistemas de negocios electrónicos tales como: comercio electrónico, gobierno electrónico, telecomunicaciones electrónicas y finanzas electrónicas; así mismo, es un sistema que trata directamente con los proveedores, no estableciendo únicamente una relación administrativa con ellos (SRM), en contraste con el sistema de apertura de datos (front office), que crea una relación administrativa del consumidor o servicio al consumidor. [4] 9

25 Beneficios del ERP Impulsa a crecer ordenadamente. Estandariza la organización Productividad de los empleados Seguridad. Toma de decisiones. Ahorro a largo plazo. [5] Limitaciones Un sistema ERP necesita ser administrado por personal capacitado para que la información que se ingresa al mismo tenga consistencia y sea fiel, si la información ingresada en el sistema no es la adecuada la información que se obtenga del sistema como resultado de un proceso no será real, adicionalmente el mantenimiento de la información de forma manual se convierte en un proceso engorrosos y muchas veces de alto costo Análisis y diseño El módulo de Control de Asistencia del sistema ERP Social realizada para la Escuela de la Unidad Educativa Corazón de Maria depende de la correcta conciliación entre la formulación completa y adecuada de los requerimientos tanto técnicos como funcionales y la planificación real y basada en los recursos con los que se cuenta para el desarrollo del proyecto, adicionalmente de la implementación de métodos de seguimiento, evaluación del sistema y control de avance Implementación Implementar un sistema informático es el despliegue en línea del funcionamiento del mismo, esto basado en especificaciones funcionales sobre las cuales se realiza el desarrollo de algoritmos y código fuente. 10

26 Seguimiento Tener una visión global del avance e inconvenientes presentados durante la ejecución del proyecto con la ejecución de un correcto seguimiento permite identificar riesgos oportunamente y tomar decisiones para resolverlas Evaluación La evaluación continua del sistema permite ir identificando dependencias de los diferentes componentes y recursos, identificara estas variables permite determinar el nivel de eficiencia y eficacia del uso de los recursos asignados al proyecto Control Es la etapa primordial en la administración de un proyecto, pues, aunque una empresa cuente con planes eficientes, una estructura organizacional adecuada y una buena dirección, sin un adecuado control que permita cerciorarse he informar del estado no se podrá verificar la situación actual de un proyecto en función de los objetivos Modelo de Desarrollo El modelo en V se encarga de representar las relaciones en el tiempo entre las fases del ciclo de desarrollo del proyecto, en él se realizan dos procesos al mismo tiempo hasta llegar a la punta de la V, conforme se reduce el espacio esto se refiere a la reducción de tiempo de cada fase y mientras más se reduce aumenta el nivel, esto puede ser prácticamente una ventaja o desventaja dependiendo del modo de trabajo de cada persona. Describe las actividades y los resultados que se producen durante el desarrollo del software. 11

27 Es una representación gráfica del ciclo de vida del desarrollo del sistema. Resume los pasos principales que hay que tomar en conjunción con las correspondientes entregas de los sistemas de validación. FIGURA 1. MODELO EN V. FUENTE: TRAVES-DEL-CICLO-DE-VIDA-DEL-SOFTWARE-I/ La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema. La parte derecha de la V representa la corriente donde se comprueba el sistema (contra las especificaciones definidas en la parte izquierda). La parte de abajo, donde se encuentran ambas partes, representa la corriente de desarrollo. La corriente de especificación consiste principalmente de: Especificaciones de requerimiento de usuario Especificaciones funcionales Especificaciones de diseño La corriente de pruebas, por su parte, suele consistir de: Calificación de instalación Calificación operacional Calificación de rendimiento 12

28 FIGURA 2. MODELO DE DESARROLLO. Fuente: En los 4 niveles lógicos comenzando desde el 1, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o validación. Esta estructura obedece que desde el principio para cada fase del desarrollo debe existir un resultado verificable. En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V, es decir de arriba hacia abajo en donde se localiza la punta. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación. 13

29 NIVEL 1 está orientado al cliente. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones. NIVEL 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional. NIVEL 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema. NIVEL 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa. [5] Ventajas: Específica bien los roles de los distintos tipos de pruebas a realizar. Hace explícito parte de la iteración y trabajo que hay que realizar. Este método involucra chequeos de cada una de las etapas del método Cascada. Es un método más robusto y completo que el método cascada y produce software de mayor calidad que con el modelo cascada. Es un modelo sencillo de y de fácil aprendizaje. Involucra al usuario en las pruebas. Desventajas: Es difícil que el cliente exponga explícitamente todos los requisitos. El cliente debe tener paciencia, ya que obtendrá el producto al final del ciclo de vida. El modelo no contempla la posibilidad de retornar etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. 14

30 Se pierde dinero, ya que si algún proceso fue mal desarrollado, este debe ser revisado de nuevo, lo que puede traer como consecuencia un "RollBack" de todo un proceso. Las pruebas pueden ser costosas y a veces no lo suficientemente efectivas Metodología En general las metodologías permiten ejecutar una serie de procesos basados en las buenas prácticas para lograr los objetivos antes mencionados. Las fases que agrupan estos procesos son las siguientes: Análisis Especificación Diseño Programación Prueba Documentación Mantenimiento Reingeniería. [9] Lenguaje de programación java Java es un lenguaje de programación orientado a objetos que se popularizó a partir del lanzamiento de su primera versión comercial de amplia difusión, la JDK 1.0 en Actualmente es uno de los lenguajes más usados para la programación en todo el mundo. [6] Simple Java posee una curva de aprendizaje muy rápida. Resulta relativamente sencillo escribir applets desde el principio. Todos aquellos familiarizados con C++ encontrarán que Java es más sencillo, ya que se han eliminado ciertas características, como los punteros. Debido a su semejanza con C 15

31 y C++, y dado que la mayoría de la gente los conoce aunque sea de forma elemental, resulta muy fácil aprender Java. Orientado al objeto Todos los conceptos en los que se apoya esta técnica, encapsulación, herencia, polimorfismo, etc., están presentes en Java. Distribuido Java proporciona una colección de clases para su uso en aplicaciones de red, que permiten abrir sockets y establecer y aceptar conexiones con servidores o clientes remotos, facilitando así la creación de aplicaciones distribuidas. Interpretado Java es compilado, en la medida en que su código fuente se transforma en una especie de código máquina, los Bytecodes semejantes a las instrucciones de ensamblador. Por otra parte, es interpretado, ya que los bytecodes se pueden ejecutar directamente sobre cualquier máquina a la cual se hayan portado el intérprete y el sistema de ejecución en tiempo real (run-time). Robusto Java fue diseñado para crear software altamente fiable. Para ello proporciona numerosas comprobaciones en compilación y en tiempo de ejecución. Sus características de memoria liberan a los programadores de una familia entera de errores (la aritmética de punteros), ya que se ha prescindido por completo de los punteros, y la recolección de basura elimina la necesidad de liberación explícita de memoria. Seguro Dada la naturaleza distribuida de Java, donde las applets se bajan desde cualquier punto de la Red, la seguridad se impuso como una necesidad de vital importancia. A nadie le gustaría ejecutar en su ordenador 16

32 programas con acceso total a su sistema, procedentes de fuentes desconocidas. Así que se implementaron barreras de seguridad en el lenguaje y en el sistema de ejecución en tiempo real. Arquitectura neutral. Java está diseñado para soportar aplicaciones que serán ejecutadas en los más variados entornos de red, desde Unix a Windows Nt, pasando por Mac y estaciones de trabajo, sobre arquitecturas distintas y con sistemas operativos diversos. Para acomodar requisitos de ejecución tan diversos, el compilador de Java genera bytecodes: un formato intermedio indiferente a la arquitectura diseñada para transportar el código eficientemente a múltiples plataformas hardware y software. El resto de problemas los soluciona el intérprete de Java. Portable La indiferencia a la arquitectura representa sólo una parte de su portabilidad. Además, Java especifica los tamaños de sus tipos de datos básicos y el comportamiento de sus operadores aritméticos, de manera que los programas son iguales en todas las plataformas. Estas dos últimas características se conocen como la Máquina Virtual Java (JVM). Produce applets. Java puede ser usado para crear dos tipos de programas: aplicaciones independientes y applets. Las aplicaciones independientes se comportan como cualquier otro programa escrito en cualquier lenguaje, como por ejemplo el navegador de Web HotJava, escrito íntegramente en Java. Por su parte, las applets son pequeños programas que aparecen embebidos en las páginas Web, como aparecen los gráficos o el texto, pero con la capacidad de ejecutar acciones muy complejas, como animar imágenes, establecer conexiones de red, presentar menús y cuadros de diálogo para luego emprender acciones, etc. 17

33 Dinámico El lenguaje Java y su sistema de ejecución en tiempo real son dinámicos en la fase de enlazado. Las clases sólo se enlazan a medida que son necesitadas. Se pueden enlazar nuevos módulos de código bajo demanda, procedente de fuentes muy variadas, incluso desde la Red. [7] Base de Datos POSTGRESQL PostgreSQL es un potente sistema de base de datos objeto-relacional de código abierto. Cuenta con más de 15 años de desarrollo activo y una arquitectura probada que se ha ganado una sólida reputación de fiabilidad e integridad de datos. Se ejecuta en los principales sistemas operativos que existen en la actualidad como: Linux UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) Windows Es totalmente compatible con ACID, tiene soporte completo para claves foráneas, uniones, vistas, disparadores y procedimientos almacenados (en varios lenguajes). Incluye la mayoría de los tipos de datos del SQL 2008, incluyendo INTEGER, numérico, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, y TIMESTAMP. También soporta almacenamiento de objetos binarios grandes, como imágenes, sonidos o vídeo. Cuenta con interfaces nativas de programación para C / C + +, Java,. Net, Perl, Python, Ruby, Tcl, ODBC, entre otros, y la documentación que actualmente existe es realmente excepcional. Una base de datos de clase empresarial, PostgreSQL cuenta con características avanzadas tales como Multi-Versión Control de concurrencia (MVCC), puntos en tiempo de recuperación, tablespaces, replicación asincrónica, transacciones anidadas (savepoints), respaldos online/hot, un sofisticado query planner/optimizer. Soporta el conjunto de caracteres internacional, codificaciones de caracteres multibyte, Unicode, mayúsculas y minúsculas. Es altamente escalable, tanto en la enorme cantidad de datos que puede manejar y en el número de usuarios concurrentes que puede administrar. Hay sistemas activos en PostgreSQL en entornos de producción que manejan más de 4 terabytes de datos. Algunos límites y características generales que se incluyen en PostgreSQL son: [8] 18

34 Tamaño máximo de la Base de datos Ilimitado Tamaño máximo de la tablas 32 TB Tamaño máximo de la fila 1.6 TB Tamaño máximo para cada campo 1 GB Máximo de filas por tabla Ilimitado Máximo de columnas por tabla dependiendo del tipo de columna Máximo de índices por tabla Ilimitado Características de Postgresql. Implementación del estándar SQL92/SQL99. Incorpora una estructura de datos array. Incorpora funciones de diversa índole: manejo de fechas, geométricas, orientada las operaciones con redes. Permite la declaración de funciones propias, así como la definición de disparadores. Soporta el uso de índices, reglas y vistas. Incluye herencia entre tablas aunque no entre objetos. Permite la gestión de diferentes usuarios, como también los permisos asignados a cada uno de ellos Ventajas de Postgressql Instalación ilimitada. Es frecuente que las bases de datos comerciales sean instaladas en más servidores de lo que permite la licencia. Algunos proveedores comerciales consideran a esto la principal fuente de incumplimiento de 19

35 licencia. Con PostgreSQL, nadie puede demandarlo por violar acuerdos de licencia, puesto que no hay costo asociado a la licencia del software. Modelos de negocios más rentables con instalaciones a gran escala. Flexibilidad para hacer investigación y desarrollo sin necesidad de incurrir en costos adicionales de licenciamiento. Mejor soporte que los proveedores comerciales Ahorros considerables en costos de operación El software ha sido diseñado y creado para tener un mantenimiento y ajuste mucho menor que los productos de los proveedores comerciales, conservando todas las características, estabilidad y rendimiento. Además de esto, nuestros programas de entrenamiento son reconocidamente mucho más costo-efectivos, manejables y prácticos en el mundo real que aquellos de los principales proveedores comerciales. Estabilidad y con fiabilidad legendarias PostgreSQL está disponible en casi cualquier Unix (34 plataformas en la última versión estable), y una versión nativa de Windows está actualmente en estado beta de pruebas. PostgreSQL usa una estrategia de almacenamiento de filas llamada MVCC para conseguir una mejor respuesta en ambientes de grandes volúmenes. Los principales proveedores de sistemas de bases de datos comerciales que usan también esta tecnología, por las mismas razones. [11] 2.3. Identificación de Variables Las variables se identificaran en base al estudio del triángulo de la gestión de Proyectos o conocido como el triángulo de hierro ; en el cual se denota La gestión de un proyecto, bajo el enfoque del PMI, nos dice que los gerentes a menudo hablan de una triple restricción: 1). Cuánto va a costar el proyecto (COSTO), 2.) Cuánto va a durar el proyecto (TIEMPO), 3.) Cuáles son las características y funciones del producto y qué trabajo debe hacerse para entregar este producto (ALCANCE). [12] 20

36 FIGURA 3. TRIÁNGULO DE GESTIÓN DE PROYECTOS. Fuente: 3/calidad.html Costo: es la asignación de fondos muchas veces de una forma no flexible, ya que es una variable dependiente no es posible fijar exactamente la cantidad total a utilizar. Tiempo: básicamente mide la duración del proyecto en base a los tiempos de cada etapa del mismo. Alcance: conjunto de características que deseamos obtener finalmente. En el centro de este triángulo estará la calidad del resultado final, el mismo será afectado si en cualquier lado del triángulo cambia. Adicionalmente a estos tres factores, aparece un cuarto elemento que es la calidad, que es la resultante del grado de cumplimiento de los otros tres factores. Esto define el nivel de calidad. En el tema de la calidad, al igual que en el de los alcances, también podemos diferenciar entre lo que significa la calidad del producto y la calidad del proceso. 21

37 FIGURA 4. PIRÁMIDE DE LA CALIDAD. Fuente: 3/calidad.html La calidad del producto es relativa, ya que depende de las expectativas del cliente. Cada perfil de cliente tiene más o menos las mismas necesidades, pero diferentes deseos y valores (estos dos últimos son fuertemente influenciados por agentes externos, tales como el marketing, la cultura, la coyuntura, etc.). Por eso, cuando definimos los alcances del producto, requerimos adecuar sus características y funciones a las expectativas y al uso del cliente final o del mercado meta. La calidad del proceso implica ejecutar la producción de la manera más eficiente posible, optimizando los trabajos que generan transformación, disminuyendo los que solamente contribuyen a ésta y tratando de eliminar todos aquellos procesos que generan pérdidas. Por otro lado, cuando definimos el alcance del proyecto, requerimos especificar sólo el trabajo requerido. Esto nos permitirá controlar y diferenciar lo que está o no está incluido en el proyecto. [13] 22

38 Variables Independientes En el presente proyecto se ha identificado al alcance como una variable independiente. El alcance del proyecto está elaborado basándose en los nuevos requerimientos de la Escuela de la Unidad Educativa Corazón de Maria, para la ejecución se identifican las siguientes actividades: Procesos que se ejecutan actualmente. Análisis de herramientas libres para la reingeniería del sistema ERP- Social. Migración del sistema ERP-Social a una nueva herramienta de desarrollo. Validación de estabilidad del sistema Capacitación a usuarios de la institución. Despliegue en ambiente productivo Variables Dependientes El alcance es directamente dependiente del costo y tiempo y afectan directamente al desarrollo del proyecto Hipótesis La visión de la Universidad Central del Ecuador al desarrollo y masificación de las TIC (Tecnologías de Información y Comunicación), hace imperante la aplicación de nuevas tecnologías en diferentes áreas para automatizar sus procesos. Resolver el problema de la automatización de la gestión de la asistencia de empleados. 23

39 Aplicar las mejores prácticas de programación para el desarrollo de proyectos que contribuyan al avance tecnológico orientado a la sociedad. Para lograr culminar y cumplir todos los objetivos de este proyecto es necesario del compromiso y participación de todos los involucrados, obteniendo como resultado un control eficaz de la asistencia de sus empleados. 24

40 CAPÍTULO III 3. METODOLOGÍA. 3.1 Metodología RUP Es una metodología objetivo es desarrollar y entregar un producto de software. Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos para su realización. Se centra en la producción y mantenimiento de modelos del sistema Principales características Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software Desarrollo iterativo Administración de requisitos 25

41 Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software Ciclo de Vida El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. FIGURA 5. CICLO DE VIDA RUP. Fuente: RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. 26

42 Fases del ciclo de vida del RUP Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto Principios clave Adaptación del proceso: El proceso debe adaptarse a las características de la organización para la que se está desarrollando el software. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto. Colaboración entre equipos: Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros. 27

43 Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteración se evaluará la calidad y estabilidad del producto y analizará la opinión y sugerencias de los inversores. Elevar el nivel de abstracción: Motivar el uso de conceptos reutilizables. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la producción. [14] Ventajas RUP se puede utilizar para proyectos grandes, medianos y pequeños. Es explicito todo lo que se debe hacer dentro del proceso de desarrollo de software. Los usuarios están involucrados continuamente. El conocimiento adquirido en una iteración puede aplicarse de iteración ha iteración Desventajas Las iteraciones en cada ciclo pueden tomar mucho más tiempo. El grado de complejidad puede no resultar muy adecuado. Requiere conocimiento del proceso y de UML El RIP es generalmente mal aplicado en el estilo cascada. [15] 28

44 3.2 Requerimientos Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Los requerimientos pueden dividirse en requerimientos funcionales y requerimientos no funcionales. 29

45 Requerimientos no funcionales Tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares. REQUERIMIENTO Disponibilidad Escalabilidad DESCRIPCION El sistema de estar disponible 24/7 y asegurar una disponibilidad mayor al 90% del tiempo. El sistema debe ser desarrollado de tal forma que se pueda integrar y actualizar con nuevos requerimientos afectando el código fuente de la menor manera posible. Facilidad de uso e ingreso de información El sistema debe ser intuitivo y de fácil entrenamiento para los usuarios. El sistema debe presentar mensajes de error que permitan al usuario identificar el tipo de error. Parametrizable Seguridad El sistema, debe ser flexible y parametrizable en la mayor parte de sus opciones. El acceso al sistema debe estar restringido por el uso de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al Sistema las personas que estén registradas, estos usuarios serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo definidas para cada rol. El sistema deberá contar con mecanismos que permitan el registro de actividades con identificación de los usuarios que los realizaron. El sistema debe contar con pistas de auditoría de las actividades que se realizan sobre el sistema. Mantenibilidad El sistema debe estar documentado tanto técnica como funcionalmente. CUADRO 1. Requerimiento no Funcional 30

46 Requerimientos funcionales Definen las funciones que el sistema será capaz de realizar, además de las transformaciones que el sistema realiza sobre las entradas para producir salidas. [16] Requerimientos Funcionales ERP Social Modulo Control de Asistencia. REQUERIMIENTO Cliente Unidad Educativa "Corazón de María" Fecha 23/05/2013 Modulo Control de Asistencia Numero 1 Sub-Modulo Registro de Empleados Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción Requerimiento del Implementación de Registro de Empleados Prioridad Alta Tiempo Registro DEV 15 días Necesario Alta Ninguno Registro del Empleado El sistema permitirá crear un nuevo empleado para llevar el control de sus asistencia, para la creación del empleado se utilizaran datos como: fotografía, CI, Nombres y Apellidos, Fecha de Nacimiento, Dirección, Número Telefónico, Numero de Afiliación, Fecha de Ingreso, Departamento, User_ID, Clave, Código de Asistencia, Estado. Dentro de la opción de Registro de empleados el usuario tendrá la opción de buscar los empleados por diferentes parámetros como: Cedula de Empleado, Nombres, Apellidos. Solución Funcional CUADRO 2. Requerimiento Funcional 1. 31

47 REQUERIMIENTO Cliente Unidad Educativa "Corazón de Maria" Fecha 23/05/2013 Modulo Control de Asistencia Numero 2 Sub-Modulo Registro Faltas Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción del Requerimiento Implementación de Registro de Faltas Registro Necesario Alta Ninguno Prioridad Tiempo DEV Alta 20 días Registro de Faltas El sistema permitirá el registro de falta de un empleado de forma manual, el proceso de registro de falta será automático al no ingresar los datos en la pantalla de autentificación. Para el registro manual se contara con los campos: Empleado, fecha de la falta, descripción. en la pantalla de registro de faltas se desplegara todas las faltas sean estas registradas de forma manual o automática, además contara con parámetros de búsqueda: cedula, nombres, apellidos Solución Funcional CUADRO 3. Requerimiento Funcional 2. 32

48 REQUERIMIENTO Cliente Unidad Educativa "Corazón de Maria" Fecha 23/05/2013 Modulo Control de Asistencia Numero 3 Sub-Modulo Parámetros Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción del Requerimiento Parametrizacion Parametrizacion Necesario Alta Ninguno Parámetros Prioridad Tiempo DEV Alta 20 días El sistema contara con dos parámetros que permitirán manejar las holguras de entrada y atrasos para el módulo de asistencia. Solución Funcional CUADRO 4. Requerimiento Funcional 3. 33

49 REQUERIMIENTO Cliente Unidad Educativa "Corazón de Maria" Fecha 23/05/2013 Modulo Control de Asistencia Numero 4 Sub-Modulo Registro de Permiso Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción del Requerimiento Implementación de Registro de Permisos Prioridad Tiempo Registro DEV Necesario Alta Ninguno Alta 20 días Registro de Permiso El sistema permitirá registrar permisos/ vacaciones de un empleado con fecha inicio y fecha fin, estas fechas a las que se asigna como permiso o vacaciones no será tomadas en cuenta para el registro de asistencia de un empleado. Solución Funcional CUADRO 5. Requerimiento Funcional 4. 34

50 REQUERIMIENTO Cliente Unidad Educativa "Corazón de Maria" Fecha 23/05/2013 Modulo Control de Asistencia Numero 5 Sub-Modulo Días Laborables Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción Requerimiento del Implementación de Parametrizacion de Días Laborables Prioridad Alta Tiempo Parametrizacion DEV 25 días Necesario Alta Ninguno Días Laborables El sistema permitirá ingresar los días no laborables para que no sean tomas en cuenta en el registro de asistencia de los empleados. Esto se lo realizara con un componente tipo calendario donde el usuario debe parametrizar los días que no serán laborables, además contara con la funcionalidad de marcado automático para fines de semana, si se desea desmarcar un día ya marcado como no laborable el sistema lo permitirá teniendo en cuenta que no se puede desmarcar fechas anteriores a la actual y este cambio se lo realizara una sola vez en cada periodo. Solución Funcional CUADRO 6. Requerimiento Funcional 5. 35

51 REQUERIMIENTO Cliente Unidad Educativa "Corazón de Maria" Fecha 23/05/2013 Modulo Control de Asistencia Numero 6 Sub-Modulo Reportes Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción del Requerimiento Implementación de Reportes Prioridad Alta Tiempo Reportes DEV 25 días Necesario Alta Ninguno Reportes El módulo de control de asistencia permitirá obtener los siguientes reportes: FALTAS devuelve un listado de faltas por usuario con la fecha de la falta. ATRASOS devuelve un listado de atrasos por usuario con la fecha de cada uno de los registros. HORAS TRABAJADAS devuelve un total de horas trabajadas en un periodo de tiempo. Todos los reportes podrán ser exportados en formato Excel y PDF Solución Funcional CUADRO 7. Requerimiento Funcional 6. 36

52 REQUERIMIENTO Cliente Unidad Educativa "Corazón de Maria" Fecha 23/05/2013 Modulo Control de Asistencia Numero 7 Sub-Modulo Horarios Estado Definido Alcance Requerimiento Tipo de Requerimiento Categoría Complejidad Módulos afectados Descripción del Requerimiento Definición de Horarios Prioridad Alta Tiempo Registro DEV 15 días Necesario Alta Ninguno Definición de Horarios El módulo de control de asistencia para la definición de horarios contara con dos funcionalidades: TIPO en la opción tipo se podrá definir varios tipos de horarios esto basado en que dentro de una misma institución y para diferentes empleados se puede tener varios horarios. DEFINICION en esta opción se definirá hora de entrada y de salida para cada tipo de horario, la funcionalidad permitirá definir horarios por día. Solución Funcional CUADRO 8. Requerimiento Funcional 7. 37

53 Requerimientos Técnicos Estos requerimientos son referentes a las características mínimas que debe poseer el servidor donde se implantara el sistema ERP Social, aquí se incluye tanto Software como Hardware Requerimientos técnicos ERP Social Servidor Los requerimientos técnicos mínimos para la implementación del sistema ERP Social son: ESPECIFICACIONES Procesador Core I3 o mayor RAM Disco duro Sistema Operativo Mínimo 4 GB. Mínimo 100 GB libres en disco.(esto en base a la capacidad y cantidad de datos que se espera incluir en la BDD) Indistinto. Windows XP/Vista/7/8, Linux (Actualmente se utilizara Centos 7) Acceso a Internet Indispensable. Software Se requiere: Adobe Reader, MS Office 2007/2010. Navegador Web Mozilla Firefox, Google Chrome. CUADRO 9. Requerimientos Técnicos Servidor. 38

54 3.3 Lenguaje de Modelamiento Unificado (UML) El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. UML está controlado por el grupo de administración de objetos (OMG) y es el estándar de descripción de esquemas de software. UML está diseñado para su uso con software orientado a objetos. UML se compone de muchos elementos de esquematización que representan las diferentes partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto de vista del sistema. UML Modeller soporta los siguientes tipos de diagramas: Diagrama de casos de uso: muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones. Diagrama de clases: muestra las clases y la relaciones entre ellas. Diagrama de secuencia: muestra los objetos y sus múltiples relaciones entre ellos. Diagrama de colaboración: muestra objetos y sus relaciones, destacando los objetos que participan en el intercambio de mensajes. Diagrama de estado: muestra estados, cambios de estado y eventos en un objeto o en parte del sistema. Diagrama de actividad: muestra actividades, así como los cambios de una a otra actividad junto con los eventos que ocurren en ciertas partes del sistema. Diagrama de componentes: que muestra los componentes de mayor nivel de la programación. Diagrama de implementación: muestra las instancias de los componentes y sus relaciones. 39

55 Diagrama de relaciones de entidad: muestra los datos y las relaciones y restricciones entre ellos. [17] Funciones de UML Dentro de los principales principales funciones: objetivos de UML se pueden resumir en sus Visualizar UML permite describir de una manera gráfica un sistema de tal forma que sea de fácil comprensión para otras personas. Especificar UML permite realizar la especificación de las características a un buen nivel del sistema a desarrollar. Construir UML sirve como base en el diseño para la construcción de los sistemas. Documentar Todos los tipos de diagramas que se elaboran basados en UML sirven como documentación Diagramas UML Un Diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. Diagrama de clases Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Los diagramas de clases son diagramas (estáticos) porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases (conocen) a qué otras clases o qué clases (son parte) de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas. [17] 40

56 Ejemplo Clase FIGURA 6. DIAGRAMA DE CLASES. FUENTE: Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). Las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos (compartimentos) dentro del rectángulo. Ejemplo FIGURA 7. CLASE. FUENTE: Atributos En UML, los atributos se muestran con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente:.+ Indica atributos públicos.# Indica atributos protegidos.- Indica atributos privados 41

57 Operaciones Las operaciones (métodos) también se muestran con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:.+ Indica operaciones públicas.# Indica operaciones protegidas.- Indica operaciones privadas Asociaciones de clases Las clases se pueden relacionar (estar asociadas) con otras de diferentes maneras: Generalización La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase (recoge) todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias. En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base. Ejemplo FIGURA 8. ASOCIACIÓN GENERALIZACIÓN. FUENTE: 42

58 Asociaciones Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de (conexiones) entre objetos. Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace). Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario. En UML, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (*) representando el infinito en el lado máximo. Ejemplo FIGURA 9. ASOCIACIÓN 1-1. FUENTE: Acumulación Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relación (completa). Una acumulación describe cómo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que actúa como completa, tiene una multiplicidad de uno. En UML, las acumulaciones están representadas por una asociación que muestra un rombo en uno de los lados de la clase completa. 43

59 Ejemplo FIGURA 10. ASOCIACIÓN ACUMULACIÓN. FUENTE: Composición Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones también forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son. En UML, las composiciones están representadas por un rombo sólido al lado del conjunto. [17] Ejemplo FIGURA 11. ASOCIACIÓN COMPOSICIÓN. FUENTE: Diagramas de Clases de ERP-Social: Módulo Matrículas Diagrama de casos de uso Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo. 44

60 Ejemplo FIGURA 12. CASOS DE USO. FUENTE: 45

61 Diagramas de Clases ERP Social: Módulo de Asistencia Definición de Persona Empleado Persona Cedula Nombres Apellidos Foto Fecha : int : char : char : byte : Date + Refrescar () : void - Codigo : int Empleado IngresarEmpleado () ConsultarEmp () ActualizarEmp () IngresarCodigo () : void : char : void : int - - Direccion Cod_Direccion Direccion : int : char + IngresarDireccion () : void - - Departamento Cod_Depno NombreDeptno : int : char + IngresarDeptno () : void FIGURA 13. DEFINICIÓN PERSONA-EMPLEADO. Método IngresaEmpleado Nombre Responsabilidad Tipo Referencia Cruzada Notas Excepciones Salida Precondiciones Public void IngresarDocente(CI,nombres,apellidos,foto,fecha, codigo,deptno) Permite registrar al empleado en la base de datos para crear después el control de asistencia Sistema Registro Empleado Registro Empleado Si no existe CI del empleado está equivocado Confirma que los datos se ingresaron en la base de datos El sistema reconoce la autentificación POSCONDICIONES Se crea una instancia para IngresaEmpleaado Los datos fueron guardados exitosamente en el sistema CUADRO 10. Método IngresaEmpleado. 46

62 Método ConsultaEmpleado Nombre Public void ConsultarEmpleado(CI, cod_control) Responsabilidad Tipo Referencia Cruzada Notas Excepciones Salida Precondiciones Permite consultar el registro de asistencia del docente en la base de datos Sistema RegistraEmpleado Utilizar índices para la consulta No exista el CI, del empleado, indicar que no es posible encontrar Historial Confirma que los datos son encontrados El sistema reconoce la autentificación POSCONDICIONES Se crea una instancia para buscar datos de Empleado El sistema muestra los datos encontrados quedando en condiciones de revisión para el administrador general exitosamente en el sistema CUADRO 11. Método ConsultaEmpleado. Método ActualizaEmpleado Nombre Public void ActualizaEmpleado(CE) Responsabilidad Permite actualizar el registro del empleado Tipo Sistema Referencia Cruzada RegistraEmpleado Notas Utilizar índices para la consulta Excepciones No exista el CE o está equivocado. No se pueden actualizar los datos Salida Precondiciones Confirma que los datos se actualizaron exitosamente en la base de datos El sistema reconoce la autentificación POSCONDICIONES Se crea una instancia para actualizar datos de Empleado El sistema muestra los datos de empleado actualizados CUADRO 12. Método ActualizaEmpleado. 47

63 Método IngresarCodigo Nombre Public void IngresarCodigo(CE) Responsabilidad Permite registrar el código de empleado en la base de datos Tipo Sistema Referencia Cruzada RegistraEmpleado Notas Excepciones No exista el CE o está equivocado. No se pueden registrar código Salida Precondiciones Confirma que el código fue ingresado exitosamente en la base de datos El sistema reconoce la autentificación POSCONDICIONES Se crea una instancia para ingreso de código del empleado El sistema muestra los datos de empleado y el código ingresado recientemente CUADRO 13. Método IngresarCodigo. Definición de Horario Horario Nombre Hora Estado : char : int : char Insertar (char nombre) () buscar (char nombre) () actualizar () : char : char : void * 0..* Ingreso Salida Holgura Insertar () Editar () Buscar () : int : int : char : char : char Año Lectivo Descripcion Estado Fecha Buscar () Insertar () Editar () : char : boolean : Date : char : char : char FIGURA 14. DEFINICIÓN HORARIO. 48

64 Caso de uso Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este. Cuando se trabaja con casos de uso, es importante tener presentes algunas reglas: Cada caso de uso está relacionado como mínimo con un actor Cada caso de uso es un iniciador (es decir, un actor) Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco») Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre casos de uso son: Include: especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso Extends: especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro. Generalización: especifica que un caso de uso hereda las características del (súper) caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases. Actor Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos. Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores. [17] 49

65 Identificación de actores de ERP-Social Actor Administrador General Administrador Módulo Director Empleado Secretaria Usuario Registrado Actividades Persona encargada de administrar las actividades, gestión y mantenimiento del ERP Persona encargada de la gestión y mantenimiento del módulo a su cargo Persona delegada para dicho cargo en la institución Sus permiso pueden variar, se puede aplicar un perfil de administrador o un perfil de consultas dependiendo sobres sus funciones en las actividades del ERP Personas o usuarios del sistema cuyos permisos son de consulta e inserción de datos Persona delegada para dicho cargo en la institución Sus permiso son de consulta e inserción de datos, sin embargo puede ser una delegada del administrador del sistema. Persona con permiso de consulta. CUADRO 14. Actores. Diagramas de Casos de Uso de ERP-Social Administrador del Módulo Inserción de Datos Validación de Permisos Director Consulta/Reportes Perfil de Usuario Empleado Secretaria Adminstración de Usuarios Administrador General FIGURA 15. CASO DE USO 1. 50

66 Casos de Uso Control de Asistencia Autentificación RegistraEmpleado Administrador general FIGURA 16. CASO DE USO 2. Especificación del Caso de Uso ESPECIFICACION DEL CASO DE USO CE Tipo Actor Referencia Pre condición Pos condición Propósito Resumen CURSO NORMAL Estimulo Actor Registrar Empleado Secundario E CI autentificación Tener acceso al sistema, estar autenticado Registrar un nuevo empleado Agregar un nuevo registro Se agrega un nuevo empleado. Se registran los datos personales. Administrador ingresa al sistema para ingresar nuevo empleado El administrador ingresa los datos del empleado El administrador para terminar con el registro solicita al empleado que ingrese su código para el ingreso El administrador guarda la activación del código. Cierra el Sistema Respuesta Sistema Sistema acoge solicitud y pide completar 2 datos personales del empleado, CI, nombres, apellidos,dirección, departamento 4 El sistema recoge datos y guarda con éxito 6 El sistema agrega el código, acepta y pide autorización para guardar 51

67 CURSO ALTERNO Estimulo Actor Respuesta Sistema 1 3 Administrador ingresa al sistema para ingresar un nuevo empleado El Administrador ingresa los datos del empleado 4 2 Sistema acoge solicitud y pide completar los datos personales del empleado CI, nombres, apellidos, dirección, departamento El sistema no se encuentra disponible. No puede realizar conexión CUADRO 15. Especificación Caso de Uso Registrar Empleado. Generación de Reportes Autentificación Verificación Usuario/Contraseña Consultar Horario Usuario Autorizado Ingresar Parámetros Generar Reporte Imprimir Reporte Consultar Nómina FIGURA 17. CASO DE USO 3. 52

68 Diagramas de secuencia Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos. En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros. [17] Ejemplo FIGURA 18. DIAGRAMA DE SECUENCIA. FUENTE: 53

69 Diagramas de Secuencia de ERP-Social SequenceDiagram_1 Autentificación BD Administrador General Valida Usuario (Contraseña) 2. Valida Usuario BD 3. Usuario Existente 4. Usuario Autentificado FIGURA 19. DIAGRAMA DE SECUENCIA AUTENTICACIÓN. 54

70 Registrar Empleado SequenceDiagram_1 Persona Empleado Dirección Departamento BD Administrador General Ingresa Empleado 2. Ingresa Datos Empleado 3. Datos Guardados Exitosamente 4. Datos Guardados 5. Ingresa Código 6. Ingresa Código CI 7. Código Guardado 8. Código Guardado Diagrama de Actividades FIGURA 20. DIAGRAMA DE SECUENCIA ADMINISTRACIÓN. FIGURA 21. DIAGRAMA DE ACTIVIDADES. 55

71 3.4 Arquitectura Modelo-Vista-Controlador El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación). De esta forma, dividimos el sistema en tres capas donde tenemos la encapsulación de los datos, la interfaz o vista y la lógica interna o controlador. El patrón de arquitectura "modelo vista controlador", es una filosofía de diseño de aplicaciones, compuesta por: Modelo Contiene el núcleo de la funcionalidad (dominio) de la aplicación. Encapsula el estado de la aplicación. No sabe nada / independiente del Controlador y la Vista. Vista Es la presentación del Modelo. Puede acceder al Modelo pero nunca cambiar su estado. Puede ser notificada cuando hay un cambio de estado en el Modelo. Controlador Reacciona a la petición del Cliente, ejecutando la acción adecuada y creando el modelo pertinente. Para entender cómo funciona nuestro patrón Modelo vista controlador, se debe entender la división a través del conjunto de estos tres elementos. Comunicación En el modelo, la vista y el controlador deben comunicarse de una manera estable los unos con los otros, de manera que sea coherente con las iteraciones que el usuario realizara. [18] 56

72 FIGURA 22. CICLO DE VIDA DE MVC. FUENTE: Diseño de la Base de Datos Estudio Previo Al inicio del proyecto, por tratarse de una reingeniería, se contó con una base de datos, la cual fue guía para definir una nueva base para el desarrollo del ERP actual; la base de datos actual ha sido diseñada con nuevos campos y relaciones de acuerdo a los requerimientos que el sistema demanda Estándares de la Base de Datos Consideraciones Generales Para nombrar cualquier objeto de la Base de Datos se deben tomar en cuenta las siguientes consideraciones generales: En ningún caso se deben utilizar nombres autogenerados por el sistema, como sucede con los constraints e índices. Los nombres de los objetos deben ser descriptivos y fáciles de entender. Los nombres de los objetos deben ser descritos con letras mayúsculas. El nombre de un objeto no debe contener palabras reservadas o caracteres especiales. 57

73 No deben contener espacios en blanco, de ser necesaria la separación de palabras se debe utilizar un guión bajo. Prefijos Todo objeto de la base de datos debe utilizar un prefijo estándar que permita relacionarlo con la aplicación, mismo que corresponderá a las tres primeras letras del nombre del módulo. Ejemplo OBJETO Empleado Estudiante Departamento Provincia PREFIJO EMP EST DEP PRO CUADRO 16. Prefijos BDD. Sufijos Todo objeto de la base de datos debe utilizar un sufijo estándar que permita identificar el tipo de objeto al que corresponde. El sufijo será el siguiente dependiendo del tipo de objeto: Ejemplo TIPO DE OBJETO Tabla Secuencia Departamento Vista Clave Primaria Clave Única Clave Foránea Índice Trigger Procedimientos Funciones Paquetes SUFIJO TBL, Sufijo de Módulo por ejemplo Control de Asistencia CDA. SEQ DEP VW PK UK FK IDX TRG PRC FUN PKG CUADRO 17. Sufijos BDD. 58

74 Nombres de Objetos Al nombrar cualquier objeto, no se debe escatimar en colocar un nombre largo, lo importante es que sea claro y descriptivo. Cuando se trata de nombres compuestos por más de una palabra, se deben eliminar las conjunciones, preposiciones y artículos. Se debe además utilizar el formato COMPLEMENTO-OBJETO-ACCIÓN; en caso de que el nombre no tuviere acción, utilizar el formato COMPLEMENTO-OBJETO. Ejemplos: Transacciones = TRANSACCIONES Detalle de Transacciones = DETALLE_TRANSACCIONES Si el nombre de un objeto excede los 30 caracteres, su tamaño debe ser reducido manteniendo el mismo lo más descriptivo posible hasta completar los 30 caracteres, utilizando el mejor criterio del desarrollador. Para reducir los nombres de los objetos se recomienda aplicar lo siguiente: Si se trata de nombres compuestos de más de una palabra, utilizar las palabras más significativas del mismo. Utilizar abreviaturas estándar. Desde la izquierda del nombre se puede remover las vocales excepto la primera letra de la palabra en caso de que esta sea una vocal. La unión entre el prefijo, el nombre del objeto y el sufijo, se lo hace por medio de un guión bajo. Campos de Tablas Para nombrar los campos de las tablas se deben tener en cuenta las siguientes consideraciones: El nombre de un campo debe ser único dentro del esquema en el que se encuentra. El nombre de un campo debe ser expresado utilizando palabras completas y debe ser lo más descriptivo posible. El nombre de cada campo tendrá un prefijo compuesto por los dos primeros caracteres del nombre de la tabla si este es una sola palabra. Si el nombre de la tabla es compuesto, se utilizará como prefijo el primer carácter de las dos primeras palabras respectivamente. 59

75 Ejemplos: Tabla: cda_empleado Campos: emp_codigo emp_estado emp_empresa Constraints Clave Primaria (Primary Key) El nombre de la clave primaria estará conformado por: El prefijo del aplicativo al cual corresponde. El nombre de la tabla Seguido del sufijo PK Unidos por un guión bajo. Ejemplo: EMP_ASISTENCIA_PK Clave Única (Unique Key) El nombre de la clave única, estará conformado por: El prefijo del aplicativo al cual corresponde. El nombre de la tabla. Seguido del sufijo UK. Seguido a su vez del número secuencial que le corresponda. Unidos por un guión bajo. Ejemplo: EMP_INGRESO_UK01 Clave Foránea (Foreign Key) El nombre de la clave foránea, está conformado por: El prefijo del aplicativo al cual corresponde. El nombre más significativo de la tabla padre. El nombre más significativo de la tabla hija. Seguido del sufijo FK. Unidos por un guión bajo. Ejemplo: Tabla padre: EMP_INGRESO_TBL Tabla hija: EMP_INGRESOSDETALLE_TBL, será: EMP_INGRESOS_DETALLLE_FK 60

76 Vistas El nombre de una vista, estará conformado por: El prefijo del aplicativo al cual corresponde. Si la vista se genera de una sola tabla, su nombre será el mismo que el de la tabla origen. Si la vista se genera de más de una tabla, tomar el nombre más significativo de cada tabla origen, unidos entre sí por un guión bajo, seguido del sufijo VW. Ejemplo: De la Tabla: EMP_INGRESOS_TBL se obtiene la vista: IMP_INGRESOS_VW Creación de la Base de Datos La base de datos del Sistema ERP-Social se ha realizado mediante PowerDesigner 15.3 que consiste en un único conjunto de herramientas que combina distintas técnicas estándares de modelado líderes en el mercado: UML, BPM, y técnicas tradicionales de diseño de base de datos; con soporte a plataformas de desarrollo.net, Workspace, PowerBuilder, Java, Eclipse, entre otros. Mediante este software se han establecido las entidades (tablas) inherentes al manejo de cada módulo que constituye el ERP-Social. La base de datos del módulo de Control de Asistencia consta de los siguientes elementos que se detalla a continuación: Diccionario de Datos Se detalla en Anexo 3. Diccionario de Base de Datos 61

77 CAPÍTULO IV 4. MARCO ADMINISTRATIVO 4.1. Recursos La ejecución del presente proyecto estará a cargo del Sr. Jose Ignacio Tovar Campaña estudiante en estado egresado de la Facultad de Ciencias Físicas y Matemáticas de la escuela de Ciencias especialidad Informática de la Universidad Central del Ecuador. Este proyecto será implementado en la Escuela de la Unidad Educativa Corazón de Maria, para la ejecución se cuenta con la aprobación del director de la Escuela de la Unidad Educativa Corazón de Maria. El equipo para le ejecución del presente proyecto está constituido de la siguiente manera: RECURSO HUMANO COMPETENCIAS N OBSERVACION Solicitante Director o Presidente de la Institución 1 o 2 Debe estar en capacidad de tomar decisiones para la institución a cargo. Ingeniero (Tutor). Informático, Conocimientos relacionados con el proyecto. 1 Debe pertenecer a la institución y será el responsable de la gestión del proyecto. Ingeniero Informático o relacionado, (Revisores). Conocimientos relacionados con el proyecto. 2 Debe pertenecer a la institución y se encargará de la revisión del documento y cumplimiento de tiempos establecidos. Tesista (Desarrollador) Análisis, diseño y desarrollo de aplicaciones web. 1 Estudiante de Ingeniería Informática de la Universidad Central del Ecuador que no pase los dos años de egresado. CUADRO 18. Recursos. 62

78 4.2. Recursos Institucionales La Escuela de la Unidad Educativa Corazón de Maria se comprometen a dar las facilidades necesarias para la implementación del presente proyecto y el personal de la institución serán los encargados del uso del mismo. En reuniones previas con la autoridad de la institución se dieron a conocer los requerimientos y soluciones a los mismos, para que el sistema supla las necesidades de la institución Recursos del autor La persona desarrolladora de éste proyecto cubrirá los gastos del proyecto durante todas las fases que implica el desarrollo de un proyecto: Fase de análisis Fase de diseño Desarrollo Pruebas Capacitación Implementación del Sistema 63

79 4.4. Costos Para la elaboración, desarrollo e implementación del presente proyecto el autor cubrirá los costos directos e indirectos que deriven hasta la finalización del proyecto. El análisis de costos se lo realizo en base a la siguiente tabla: ITEM Cantidad Valor Unitario Nº Nº $ $ 1 SUBTOTAL UCE 2 SUBTOTAL EMPRESA 3 4 Valor Uso de equipo de la empresa Horas Personal de apoyo Horas Tutor de trabajo de graduación Horas Tribunal de trabajo de graduación Horas Investigador (autor de trabajo de grado) Horas Impresora laser Unidad Tóner Unidad Flash memory Unidad Copias Unidad ,03 60 SUBTOTAL DE RECURSOS MATERIALES 5 SUBTOTAL OTROS TOTAL IMPREVISTOS (5%) TOTAL DEL PRESUPUESTO FINANCIAMIENTO RECURSOS HUMANOS SUBTOTAL RECURSOS HUMANOS RUBRO RECURSOS INSTITUCIONALES UCE RECURSOS EMPRESARIALES EMPRESA Materias primas: RECURSOS MATERIALES Material de escritorio: Unidad OTROS (Gastos: agua, luz, telf.) Días 400 0, Credenciales Unidad Horas Hombre Horas Transporte Días 85 1,5 127,5 Internet Meses Uso de equipo personal Horas 500 0, , ,75 UCE (ÍTEM 1+3) 0 EMPRESA (ÍTEM 2) 0 ALUMNO (ÍTEM 4+5) 3900,75 CUADRO 19. Costos. 64

80 CAPITULO V 5. Conclusiones y Recomendaciones Una vez finalizado el proyecto de graduación en el que se cumplió con todos los objetivos planteados para el desarrollo de la implementación y reingeniería del sistema ERP Social se han generado las siguientes conclusiones y recomendaciones en base a lo desarrollado: 5.1. Conclusiones Terminada la implementación del módulo Control de Asistencia en la Escuela de la Unidad Educativa Corazón de Maria se obtuvieron las siguientes conclusiones. La parametrizacion, el cambio de herramientas de desarrollo y el cambio de la planificación incidieron directamente en los costos del presente proyecto. La implementación de un sistema Web en instituciones públicas permite mejorar sus servicios y ahorrar tanto en costos como en tiempos para la ejecución de sus procesos. Mediante la reingeniería del sistema ERP Social a nuevas tecnologías de desarrollo como es JAVA ha permitido obtener como producto final un sistema más amigable, robusto y permite a las instituciones acceder a su información de manera Online. La implementación del sistema ERP Social modulo Control de Asistencia automatiza un proceso que se llevaba de forma manual en la institución. La utilización del leguaje UML permitió al desarrollador entender de una manera más clara y explícita la lógica de lo que el usuario especifico en los requerimientos iniciales. El soporte primordial sobre el cual se sustenta un sistema ERP es la lógica de negocio y el diseño de la BDD que es la raíz de la organización de los datos de cada institución. En la práctica se puede evidenciar que con la implantación del módulo de Control de Asistencia se ha reducido el tiempo de ejecución de este proceso en las diferentes instituciones. 65

81 La utilización de herramientas de desarrollo libres tales como JAVA y Postgres en BDD permite que el sistema tenga un alto índice de fiabilidad y no tenga dependencias de licencias para su utilización Recomendaciones Al finalizar el presente proyecto se puede destacar las siguientes recomendaciones: El personal a cargo de la parametrizacion y manejo del módulo de Control de Asistencia debe tener conocimientos básicos de informática. Si posteriormente a la implementación del sistema ERP Social nacen nuevos requerimientos se debe informar por cualquier medio de contacto. Los medios por los cuales se accederá al sistema ERP Social debe cumplir con los requerimientos técnicos de hardware y software. La conexión a internet debe ser estable. 66

82 GLOSARIO A Array: En programación, es una zona de almacenamiento continuo, que contiene una serie de elementos del mismo tipo. Desde el punto de vista lógico se puede ver como un conjunto de elementos ordenados en fila. B BSD: en español, Distribución de Software Berkeley fue un sistema operativo derivado del sistema Unix nacido a partir de los aportes realizados a ese sistema por la Universidad de California en Berkeley. Bytecode: es un código intermedio más abstracto que el código máquina. Habitualmente es tratado como un archivo binario que contiene un programa ejecutable similar a un módulo objeto, que es un archivo binario producido por el compilador cuyo contenido es el código objeto o código máquina. D Dialéctica: es el nombre que recibe aquella parte de la Filosofía que se ocupa del razonamiento y de las leyes de éste, las formas y las maneras de expresarse. Digitalización: convertir en digital información analógica. Es convertir cualquier señal de entrada continua (analógica) en una serie de valores numéricos. Por ejemplo, una fotografía en papel puede digitalizarse para que pueda ser procesada en una computadora (u otro dispositivo similar). La información digital es la única información que puede procesar una computadora, generalmente en sistema binario. E E-learning: es la educación a distancia completamente virtualizado a través de los nuevos canales electrónicos (las nuevas redes de comunicación, en especial Internet), utilizando para ello herramientas o aplicaciones de hipertexto (correo electrónico, páginas web, foros de discusión, mensajería instantánea) como soporte de los procesos de enseñanza-aprendizaje. ERP: Sistemas de Información Gerenciales que integran y manejan negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía en la producción de bienes o servicios. 67

83 F FTP: File Transfer Protocol ; en español 'Protocolo de Transferencia de Archivos', es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. H HTML: (HyperText Markup Language); en español lenguaje de marcas de hipertexto, hace referencia al lenguaje de marcado para la elaboración de páginas web. Es un estándar que sirve de referencia para la elaboración de páginas web en sus diferentes versiones, define una estructura básica y un código (denominado código HTML) para la definición de contenido de una página web, como texto, imágenes, entre otros. HTTP: HyperText Transfer Protocol; en español Protocolo de transferencia de hipertexto es el método más común de intercambio de información en la world wide web, el método mediante el cual se transfieren las páginas web a un ordenador. J JSF: JavaServer Faces es una tecnología y framework para aplicaciones Java basadas en web que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE. JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a otras tecnologías L Logística: conjunto de medios y métodos necesarios para llevar a cabo la organización de una empresa, o de un servicio, especialmente de distribución. M Migración: consiste en la transferencia de materiales digitales de un origen de datos a otro, transformando la forma lógica del ente digital de modo que el objeto conceptual pueda ser restituido o presentado por un nuevo equipo o programa informático. Se trata de una consideración clave para cualquier implementación, actualización o consolidación de un sistema informático. 68

84 Módulo: es una porción de un programa de computadora. De las varias tareas que debe realizar un programa para cumplir con su función u objetivos, un módulo realizará, comúnmente, una de dichas tareas. MVC: es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. O Optimizar: Buscar la mejor manera de realizar una actividad. P PGDG: PostgreSQL Global Development Group, comunidad de desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyados por organizaciones comerciales en el proyecto PostgreSQL. Premisas: es cada una de las proposiciones anteriores a la conclusión de un argumento. En un argumento válido, las premisas implican la conclusión, pero esto no es necesario para que una proposición sea una premisa: lo único relevante es su lugar en el argumento, no su rol. Al ser proposiciones, las premisas siempre afirman o niegan algo y pueden ser verdaderas o falsas. R Reingeniería: Es el rediseño de un proceso en un negocio o un cambio drástico de un proceso. Recupera información sobre el diseño de un programa existente, con vistas a adaptarlo a un cambio, a ampliarlo o a mejorar su calidad general, con el objetivo de conseguir una mayor facilidad de mantenimiento en el futuro. Requerimiento: En ingeniería del software y el desarrollo de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Los requerimientos son declaraciones que identifican atributos, capacidades o características y/o cualidades que necesita cumplir un sistema para que tenga valor y utilidad para el usuario. 69

85 RollBack: En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un servidor de base de datos; realizando rollback (devuelto) cualquier transacción que estuviera activa en el tiempo del crash, la base de datos es restaurada a un estado consistente. V Versatilidad: Facilidad grande para el cambio, sobre todo de genio o carácter. 70

86 REFERENCIAS BIBLIOGRÁFICAS 1. Florencia Chiesa. (2004). Metodología para Selección De Sistemas ERP. Extraído el 14 de junio de 2013 desde 2. Misión y Visión Universidad Central del Ecuador Facultad de Ingeniería Ciencias Físicas y Matemática. Consultado el día 4 de marzo de 2013 desde 3. Misión y Visión Universidad Central del Ecuador Facultad de Ingeniería Ciencias Físicas y Matemática. Consultado el día 4 de marzo de 2013 desde 4. Asesoría informática WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde 5. Buscas el mejor Software ERP para tu negocio? (n.d). Extraído 19 de Julio de 2014 desde 6. Aprender aprogramar en jav WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde 8:ique-es-java-concepto-de-programacion-orientada-a-objetos-vs-programacionestructurada-cu00603b&catid=68:curso-aprender-programacion-java-desdecero&Itemid= JAVA. (n.d). Extraído 15 de Julio de 2013 desde guaje 8. BDD Extraído 25 de Agosto de 2014 desde 9. Introducción Ingeniería WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde Java WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde Posgresql WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde LA PIRÁMIDE DE LA CALIDAD WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde Akao, J. y Manssur, G. (2003). The leading edge in QFD: past, present and future, International Journal of Quality and Reliability Management, Volumen 20 N 1, West Yorkshire, England. 71

87 14. Desarrollando aplicaciones informáticas con el Proceso de Desarrollo Unificado (RUP). (n.d). Extraído 19 de Julio de 2014 desde mindmeister (n.d). Extraído 19 de Julio de 2014 desde requerimientos (n.d). Extraído 19 de Julio de 2014 desde Introducción a UML (n.d). Extraído 19 de Julio de 2014 desde Patrón de arquitectura Modelo Vista Controlador (n.d). Extraído 19 de Julio de 2014 desde 72

88 ANEXO I Vista ACCESO: En la tabla se guardan toda la información del acceso primario de Administradores de Seguridad para el acceso general al sistema la cual posee los atributos código, nombre y contraseña. Nombre del Tipo Nulo Descripción Atributo CODIGO Integer Not null Código del Administrador NOMBRE String (20) Not null Nombre del Administrador CONTRASEÑA Integer (10) Not null Contraseña del Administrador para el acceso Vista ACCESO1: En la tabla se guardan toda la información del acceso primario de Administradores para el acceso general al sistema la cual posee los atributos código, nombre y contraseña. Nombre del Tipo Nulo Descripción Atributo CODIGO Integer Not null Código del Administrador NOMBRE String (20) Not null Nombre del Administrador CONTRASEÑA Integer (10) Not null Contraseña del Administrador para el acceso 73

89 Vista USUARIOS: En la tabla se guardan toda la información de los Registros completos de Usuarios la cual posee los atributos código, cedula, nombres, apellidos, dirección, teléfonos, sexo, área y fecha_ingreso. Nombre del Tipo Nulo Descripción Atributo CODIGO Integer Not null Código de los Usuarios CEDULA Integer (20) Not null Cedula de los Usuarios NOMBRES String (10) Not null Nombre de los Usuarios completos APELLIDOS String (10) Not null Apellidos Usuarios DIRECCIÓN Date (10) Not null Direcciones de los Usuarios para su ubicación TELFONO_CELL Integer(03) Not null Codigo del celular para Usuarios TELEFONOS Integer (20) Not null Teléfonos de los Usuarios para contactarlo SEXO String (20) Not null Sexo de Usuarios AREA String (30) Not null Area en la cual se desempeña o Administran los Usuarios FECHA_INGRES O Date (10) Not null Fecha en la cual ingreso a laborar los Usuarios 74

90 Vista ADMINISTRADORES: En la tabla se guardan toda la información de los Registros completos de Administradores la cual posee los atributos código, cedula, nombres, apellidos, dirección, teléfonos, sexo y fecha_ingreso. Nombre del Tipo Nulo Descripción Atributo CODIGO Integer Not null Código de los Administradores CEDULA Integer (20) Not null Cedula de los Administradores NOMBRES String (10) Not null Nombre de los Administradores completos APELLIDOS String (10) Not null Apellidos Administradores DIRECCIÓN Date (10) Not null Dirección de Administradores TELEFONO_CE L Integer(03) Not null Codigo del celular para Administradores TELEFONOS Integer (20) Not null Teléfonos de los Administradores SEXO String (20) Not null Sexo de Administradores FECHA_INGRES O Date (10) Not null Fecha en la cual ingreso a gestionar el Administrador 75

91 Vista ASISTENCIA_EMPLEADOS En la tabla se guardan toda la información de las Asistencias de Usuarios: Nombre Atributo ID del Tipo Nulo Descripción Integer- Contador(3) Not null Identificador y secuenciador para la repetición de las asistencias CODIGO Integer (10) Not null Código de los Usuarios CEDULA Integer (20) Not null Cedula de Usuarios NOMBRES String (10) Not null Nombre Empleados APELLIDOS String (10) Not null Apellidos de los Usuarios DIRECCIÓN Date (10) Not null Dirección de los Usuarios TELEFONOS Integer (20) Not null Teléfonos de los Usuarios SEXO String (20) Not null Sexo de los Usuarios AREA String (30) Not null Área en la cual se FECHA_INGRES O desempeña el usuario Date (10) Not null Fecha en la cual ingreso a laborar el usuario FECHA_ASISTE Date (10) Not null Fecha en que se ha NCIA tomado la asistencia del Usuario DIAS_SEMANA String (10) Not null Días las cuales el empleado ha asistido. HORA_ENTRAD Date (10) Not null Hora de entrada A HORA_SALIDA Date (10) Not null Hora de salida HORARIO String (2) Not null El horario el cual trabaja el usuario 76

92 MANUAL DE USUARIO ANEXO II Contenido Pantalla inicial Cabecera Menú Menú Control de Asistencia Reporte de horas Trabajadas Reporte de Faltas Reporte de Atrasos Definición de día Laboral Registro de Permisos Definición de tipos de horarios Parámetros de Ingreso Registro manual de Faltas Registro de nuevo empleado Definición de horarios

93 Pantalla inicial Al ingreso a la URL del sistema se presentara la pantalla de login al sistema URL: En la pantalla de login se tendrá los siguientes campos: Usuario: se debe ingresar el nombre de usuario asignado el momento de la creación de usuario. Clave: código de ingreso asignado el momento de la creación de usuario. Botón Ingresar: permite la validación de los campos Usuario y Clave para permitir el acceso al sistema. Si el usuario no es correcto se presentara el siguiente mensaje al usuario. 78

94 Si la clave no es correcta se presentara el siguiente mensaje al usuario Si el usuario y la clave ingresados son correctos se permitirá el acceso al sistema Cabecera 79

95 En cabecera se encontraran las siguientes opciones: Inicio: redirige a la página principal Ayuda: permite un link a los manuales del sistema. Cerrar Sesión: permite culminar la sesión del usuario logueado Adicionalmente se presentaran: Empresa: corresponde a la empresa a la que pertenece el usuario logueado. Usuario: nombre del usuario logueado. Menú En la cabecera del menú se presentara el botón el cual permite la utilización de la función menú colapsable, esto permite ocultar el menú y visualizar el área de trabajo de una mejor forma. 80

96 Para mostrar el menú nuevamente se utilizara el botón izquierda del área de trabajo. que se presentara en la parte superior Menú Control de Asistencia 81

97 Reporte de horas Trabajadas Este reporte presentara la información de las horas trabajadas por usuario. Refrescar: permite la actualización de la información que se presenta en pantalla. Parámetros de búsqueda Fecha: permite realizar la búsqueda por fechas. Código Empleado: permite realizar la búsqueda por el código del empleado. Nombres Empleado: permite realizar la búsqueda por el nombre de empleados. Apellidos Empleados: permite realizar la búsqueda por apellidos de los empleados. Buscar: permite ejecutar la búsqueda. Si no se ingresa ninguno de los parámetros de búsqueda el sistema de volverá todos los registros de los que dispone. Resultados #: Número de ítem que devuelve el sistema. Cedula Empleado: número de cedula del empleado del que se devuelve el registro. 82

98 Apellidos Empleado: apellidos del empleado del que se devuelve el registro. Nombres Empleado: nombres del empleado del que se devuelve el registro. Opciones: permite visualizar todos los registros asociados al usuario que devuelve el registro. Al dar clic sobre la opción se desplegara la siguiente pantalla: El registro presentara la hora de ingreso, la hora de salida y el total de horas trabajas por ítem. Este reporte puede ser exportado en dos formatos Excel y PDF desde las opciones: 83

99 Reporte de Faltas El reporte de faltas permite obtener un listado de usuarios con las fechas en las que el sistema ha registrado una inasistencia a sus labores, se debe tener en cuenta que el sistema registra como falta si el empleado se registra luego de la holgura permitida para atrasos. Este reporte puede ser exportado a formato Excel y PDF desde la opción: Para realizar la búsqueda se puede utilizar varios parámetros como: Cedula Empleado Nombres de Empleado Apellido Empleado Los resultados del reporte contiene la siguiente información: Cedula de Empleado Nombre de Empleado Apellido Empleado Dirección Empleado Fecha 84

100 Reporte de Atrasos Esta opción permite obtener un listado de atrasos por cada usuario, en el que presenta el listado por cada registro. Para realizar la búsqueda se puede utilizar varios parámetros como: Cedula Empleado Nombres de Empleado Apellido Empleado Los resultados del reporte contiene la siguiente información: Cedula de Empleado Nombre de Empleado Apellido Empleado Dirección Empleado Fecha nacimiento Opciones Al dar clic en el botón se despliega la siguiente pantalla: 85

101 Aquí se presenta la hora de entrada y hora de salida para el registro de atraso. Este reporte es posible exportarlo a formato Excel y PDF desde la opción: Definición de día Laboral En esta opción el usuario administrador podrá definir en un catálogo tipo calendario las fechas de días no laborables, el sistema presenta la opción de calendarizar por defecto todos los sábados y domingos como días no laborables. Nota: se debe tener en cuenta que una vez realizada la parametrizacion de los días no laborables no es posible cambiar para el año presente. Para definir una fecha como día no laboral se debe dar doble clic sobre el dia y se presentara la siguiente pantalla. En el campo observación se debe ingresar la razón por la que se marca como día no laborable, al dar clic el sistema registra como día no laborable. 86

102 Registro de Permisos Esta opción permitir registrar las fechas en las cuales el sistema no tomara como inasistencias a un empleado, el registro de permisos permite ingresar una fecha específica, también se la puede utilizar para registrar los días de vacaciones de los empleados. Para realizar la búsqueda se puede utilizar varios parámetros como: Cedula Empleado Nombres de Empleado Apellido Empleado Los resultados del reporte contiene la siguiente información: Cedula de Empleado Nombre de Empleado Apellido Empleado Fecha Para registrar un permiso se debe dar clic en la opción pantalla:, se presentara la siguiente 87

103 En el campo Empleado Permiso se registra el nombre del empleado al que se está signando el permiso. En el campo Fecha permiso se desplegara el componente calendario en el cual se debe marcar la fecha de permiso. Para guardar el nuevo registro se debe dar clic en el botón Definición de tipos de horarios Esta opción permite crear varios tipos de horarios, ya que las instituciones pueden tener varios horarios para diferentes empleados, aquí solo se crea el tipo que luego será utilizado en la definición de los horarios. 88

104 Al dar clic sobre la opción se desplegar ala siguiente pantalla: Esta opción permite modificar un registro ingresado. Para ingresar un nuevo registro se debe dar clic en el botón pantalla:, se desplegara la siguiente En el campo descripción tipo se debe ingresar el identificativo del tipo de horario que se desea crear. Para guardar los cambios se debe dar clic sobre el botón Parámetros de Ingreso Esta opción permite definir la holgura para el registro de atraso y falta, la formula aplicada por el sistema para el registro es la siguiente: Hora de ingreso-2 horas hasta hora de ingreso = sistema registra como a tiempo. Hora de ingreso hasta hora de ingreso + holgura = sistema registra como atraso. Hora de ingreso + holgura en adelante el sistema registra como falta. El valor del parámetro se lo ingresara en números y será medido en minutos. El parámetro será creado por defecto y solo será modificable su valor para cada institución. 89

105 Registro manual de Faltas Esta opción permite al usuario ingresar de forma manual un registro de falta. Para registrar una falta de forma manual se debe dar clic en el botón Se desplegara la siguiente pantalla: 90

106 En el campo Empleado Falta se registrara el nombre del empleado. En el campo Fecha Falta se desplegara el componente tipo calendario para escoger la fecha de asignación del registro. Registro de nuevo empleado Esta opción permite inscribir un nuevo empleado de la empresa para el registro de asistencia. Para realizar la búsqueda se puede utilizar varios parámetros como: Cedula Empleado Nombres de Empleado Apellido Empleado Los resultados del reporte contiene la siguiente información: Nombres Apellidos Identificación Dirección Fecha de nacimiento Opciones 91

107 Al dar clic sobre el botón se desplegara la siguiente pantalla para actualización de datos del empleado escogido del listado de registros presentados. Para ingresar un nuevo empleado para el sistema de control de asistencia se debe dar clic en el botón, se desplegara la siguiente pantalla: 92

108 Foto empleado: se puede adjuntar la fotografía del empleado desde una ubicación de memoria del computador. Cedula del empleado: identificación del empleado Nombres Empleado: nombres del empleado Apellidos Empleado: apellidos del empleado Fecha Nacimiento Empleado: fecha de nacimiento del empleado Dirección Empleado: dirección domiciliaria del empleado Celular Empleado: número de móvil del empleado Empleado: dirección electrónica del empleado Afiliación Empleado: número de afiliación del empleado Fecha de Ingreso: fecha de ingreso a la institución Departamento Empleado: departamento al que pertenece el empleado Usuario Empleado: se define el username que utilizara el empleado para su registro en el sistema Clave Empleado: clave que utilizara el empleado para el registro en el sistema Código de asistencia: código único que se asigna al empleado Estado: si el check está marcado el empleado está en estado activo caso contrario no Tipo Horario: tipo de horario que se asigna al empleado y que será el parámetro para el registro de entrada y salida. 93

109 Definición de horarios Esta opción permite definir los horarios por tipo, la definición de los horarios permite discriminar por día hora de entrada y de salida para cada tipo de horario. Para realizar la búsqueda de los parámetros de horario se utiliza el tipo de horario. Para insertar los parámetros de un tipo de horario se debe dar clic en el botón desplegara la siguiente pantalla. se Tipo: lista desplegable donde se presentara los tipos de horario ingresados. Día: lista desplegable donde se presentara los días de la semana. Hora de Inicio: lista desplegable donde se escoge el horario de ingreso. Hora de Salida: lista desplegable donde se escoge el horario de salida. 94