universidad central del ecuador...padre tarquino al que no pude darle la alegría de verme graduado...
TRANSCRIPT
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
II
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
III
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
IV
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: 1717828030
V
CERTIFICACION DEL TUTOR
VI
NOTIFICACIÓN DE TRIBUNAL
VII
RESULTADO DEL TRABAJO DE GRADUACIÓN
VIII
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 2
1.1. Planteamiento del Problema 2
1.2. Formulación del Problema 3
1.3. Interrogantes de la Investigación 4
1.4. Objetivo de la Investigación 4
1.5. Objetivo General 4
1.6. Objetivos Específicos 5
1.7. Justificación 5
1.8. Alcance 6
1.9. Limitaciones 7
CAPITULO II 8
2. REVISIÓN BIBLIOGRÁFICA 8
2.1. Antecedentes 8
2.2. Marco Teórico 9
2.2.1. Beneficios del ERP 10
2.2.2. Limitaciones 10
2.2.3. Análisis y diseño 10
2.2.4. Implementación 10
2.2.5. Seguimiento 11
2.2.6. Evaluación 11
2.2.7. Control 11
2.2.8. Modelo de Desarrollo 11
2.2.9. Metodología 15
2.2.10. Lenguaje de programación java 15
IX
2.2.11. Base de Datos 18
2.3. Identificación de Variables 20
2.3.1. Variables Independientes 23
2.3.2. Variables Dependientes 23
2.4. Hipótesis 23
CAPÍTULO III 25
3. METODOLOGÍA. 25
3.1 Metodología RUP 25
3.1.1. Principales características 25
3.1.2. Ciclo de Vida 26
3.1.3. Fases del ciclo de vida del RUP 27
3.1.4. Principios clave 27
3.1.5. Ventajas 28
3.1.6. Desventajas 28
3.2 Requerimientos 29
3.2.1. Requerimientos no funcionales 30
3.2.2. Requerimientos funcionales 31
3.2.3. Requerimientos Técnicos 38
3.3 Lenguaje de Modelamiento Unificado (UML) 39
3.3.1. Funciones de UML 40
3.3.2. Diagramas UML 40
3.4 Arquitectura Modelo-Vista-Controlador 56
3.5 Diseño de la Base de Datos 57
3.5.1. Estudio Previo 57
3.5.2. Estándares de la Base de Datos 57
3.5.3. Creación de la Base de Datos 61
3.5.4. Diccionario de Datos 61
CAPÍTULO IV 62
4. MARCO ADMINISTRATIVO 62
4.1. Recursos 62
4.2. Recursos Institucionales 63
4.3. Recursos del autor 63
4.4. Costos 64
CAPITULO V 65
5. Conclusiones y Recomendaciones 65
5.1. Conclusiones 65
5.2. Recomendaciones 66
GLOSARIO 67
REFERENCIAS BIBLIOGRÁFICAS 71
ANEXO I 73
ANEXO II 77
X
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 1-1. 43
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 1. 50
FIGURA 16. CASO DE USO 2. 51
FIGURA 17. CASO DE USO 3. 52
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
XI
LISTA DE TABLAS
CUADRO 1. REQUERIMIENTO NO FUNCIONAL 30
CUADRO 2. REQUERIMIENTO FUNCIONAL 1. 31
CUADRO 3. REQUERIMIENTO FUNCIONAL 2. 32
CUADRO 4. REQUERIMIENTO FUNCIONAL 3. 33
CUADRO 5. REQUERIMIENTO FUNCIONAL 4. 34
CUADRO 6. REQUERIMIENTO FUNCIONAL 5. 35
CUADRO 7. REQUERIMIENTO FUNCIONAL 6. 36
CUADRO 8. REQUERIMIENTO FUNCIONAL 7. 37
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
XII
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
XIII
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
XIV
CERTIFICADO DE TRADUCCIÓN
XV
TÍTULO
1
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.
2
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í.
3
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.
4
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.
1.5. 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.
5
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.
1.7. 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.
6
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.
1.8. 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.
7
1.9. Limitaciones
Las posibles limitaciones que pueden restringir el desarrollo o uso del
sistema a desarrollar son:
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.
8
CAPITULO II
2. REVISIÓN BIBLIOGRÁFICA
2.1. Antecedentes
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 2011-2012, 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
38000 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.
9
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]
10
2.2.1. Beneficios del ERP
Impulsa a crecer ordenadamente.
Estandariza la organización
Productividad de los empleados
Seguridad.
Toma de decisiones.
Ahorro a largo plazo. [5]
2.2.2. 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.
2.2.3. 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.
2.2.4. 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.
11
2.2.5. 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.
2.2.6. 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.
2.2.7. 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.
2.2.8. 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.
12
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: HTTPS://JOSEPABLOSARCO.WORDPRESS.COM/2012/03/24/ISTQB-CAP-2-TESTING-A-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
13
FIGURA 2. MODELO DE DESARROLLO.
Fuente: http://ingenieriadesoftware.mex.tl/61885_Modelo-V.html
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.
14
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.
15
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.
2.2.9. 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]
2.2.10. 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 1996. 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
16
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
17
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.
18
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]
2.2.11. 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]
19
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 250-1600 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
20
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]
21
FIGURA 3. TRIÁNGULO DE GESTIÓN DE PROYECTOS.
Fuente: http://www.acerosarequipa.com/construccion-industrial/boletin-construccion-integral/edicion-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.
22
FIGURA 4. PIRÁMIDE DE LA CALIDAD.
Fuente: http://www.acerosarequipa.com/construccion-industrial/boletin-construccion-integral/edicion-
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]
23
2.3.1. 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.
2.3.2. Variables Dependientes
El alcance es directamente dependiente del costo y tiempo y afectan
directamente al desarrollo del proyecto.
2.4. 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.
24
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.
25
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.
3.1.1. 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
26
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificación de la calidad del software
3.1.2. 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: http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm
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.
27
3.1.3. 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.
3.1.4. 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.
28
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]
3.1.5. 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.
3.1.6. 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]
29
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.
30
3.2.1. 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 DESCRIPCION
Disponibilidad El sistema de estar disponible 24/7 y asegurar una disponibilidad mayor al 90% del tiempo.
Escalabilidad 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 El sistema, debe ser flexible y parametrizable en la mayor parte de sus opciones.
Seguridad
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
31
3.2.2. 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 Implementación de Registro de Empleados Prioridad Alta
Tipo de Requerimiento Registro Tiempo DEV 15 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento Registro del Empleado
Solución Funcional
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.
CUADRO 2. Requerimiento Funcional 1.
32
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 Implementación de Registro de Faltas Prioridad Alta
Tipo de Requerimiento Registro Tiempo DEV 20 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento Registro de Faltas
Solución Funcional
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
CUADRO 3. Requerimiento Funcional 2.
33
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 Parametrizacion Prioridad Alta
Tipo de Requerimiento Parametrizacion Tiempo DEV
20 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento
Parámetros
Solución Funcional
El sistema contara con dos parámetros que permitirán manejar las holguras de entrada y atrasos para el módulo de asistencia.
CUADRO 4. Requerimiento Funcional 3.
34
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 Implementación de Registro de Permisos Prioridad Alta
Tipo de Requerimiento Registro Tiempo DEV 20 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento Registro de Permiso
Solución Funcional
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.
CUADRO 5. Requerimiento Funcional 4.
35
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 Implementación de Parametrizacion de Días Laborables Prioridad Alta
Tipo de Requerimiento Parametrizacion Tiempo DEV 25 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento Días Laborables
Solución Funcional
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.
CUADRO 6. Requerimiento Funcional 5.
36
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 Implementación de Reportes Prioridad Alta
Tipo de Requerimiento Reportes Tiempo DEV 25 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento Reportes
Solución Funcional
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
CUADRO 7. Requerimiento Funcional 6.
37
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 Definición de Horarios Prioridad Alta
Tipo de Requerimiento Registro Tiempo DEV 15 días
Categoría Necesario
Complejidad Alta
Módulos afectados Ninguno
Descripción del Requerimiento Definición de Horarios
Solución Funcional
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.
CUADRO 8. Requerimiento Funcional 7.
38
3.2.3. 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 Mínimo 4 GB.
Disco duro Mínimo 100 GB libres en disco.(esto en base a la capacidad y cantidad de datos que se espera incluir en la BDD)
Sistema Operativo
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.
39
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.
40
Diagrama de relaciones de entidad: muestra los datos y las relaciones y
restricciones entre ellos. [17]
3.3.1. Funciones de UML
Dentro de los principales objetivos de UML se pueden resumir en sus
principales funciones:
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.
3.3.2. 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]
41
Ejemplo
FIGURA 6. DIAGRAMA DE CLASES.
FUENTE: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
Clase
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: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
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
42
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: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
43
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: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
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.
44
Ejemplo
FIGURA 10. ASOCIACIÓN ACUMULACIÓN.
FUENTE: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
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: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
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.
45
Ejemplo
FIGURA 12. CASOS DE USO.
FUENTE: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
46
Diagramas de Clases ERP – Social: Módulo de Asistencia
Definición de Persona – Empleado
FIGURA 13. DEFINICIÓN PERSONA-EMPLEADO.
Método IngresaEmpleado
Nombre Public void IngresarDocente(CI,nombres,apellidos,foto,fecha, codigo,deptno)
Responsabilidad Permite registrar al empleado en la base de datos para crear después el control de asistencia
Tipo Sistema
Referencia Cruzada Registro Empleado
Notas Registro Empleado
Excepciones Si no existe CI del empleado está equivocado
Salida Confirma que los datos se ingresaron en la base de datos
Precondiciones 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.
Persona
-
-
-
-
-
Cedula
Nombres
Apellidos
Foto
Fecha
: int
: char
: char
: byte
: Date
+ Refrescar () : void
Empleado
- Codigo : int
+
+
+
+
IngresarEmpleado ()
ConsultarEmp ()
ActualizarEmp ()
IngresarCodigo ()
: void
: char
: void
: int
Direccion
-
-
Cod_Direccion
Direccion
: int
: char
+ IngresarDireccion () : void
Departamento
-
-
Cod_Depno
NombreDeptno
: int
: char
+ IngresarDeptno () : void
47
Método ConsultaEmpleado
Nombre Public void ConsultarEmpleado(CI, cod_Control)
Responsabilidad Permite consultar el registro de asistencia del docente en la base de datos
Tipo Sistema
Referencia Cruzada RegistraEmpleado
Notas Utilizar índices para la consulta
Excepciones No exista el CI, del empleado, indicar que no es posible encontrar Historial
Salida Confirma que los datos son encontrados
Precondiciones 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 Confirma que los datos se actualizaron exitosamente en la base de datos
Precondiciones 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.
48
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 Confirma que el código fue ingresado exitosamente en la base de datos
Precondiciones 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
FIGURA 14. DEFINICIÓN HORARIO.
0..1
0..*
0..1
0..*
Horario
-
-
-
Nombre
Hora
Estado
: char
: int
: char
+
+
+
Insertar (char nombre) ()
buscar (char nombre) ()
actualizar ()
: char
: char
: void
Año Lectivo
-
-
-
Descripcion
Estado
Fecha
: char
: boolean
: Date
+
+
+
Buscar ()
Insertar ()
Editar ()
: char
: char
: char
Holgura
-
-
Ingreso
Salida
: int
: int
+
+
+
Insertar ()
Editar ()
Buscar ()
: char
: char
: char
49
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]
50
Identificación de actores de ERP-Social
Actor Actividades
Administrador General Persona encargada de administrar las actividades, gestión y mantenimiento del ERP
Administrador Módulo
Persona encargada de la gestión y mantenimiento del módulo a su cargo
Director
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
Empleado Personas o usuarios del sistema cuyos permisos son de consulta e inserción de datos
Secretaria 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.
Usuario Registrado Persona con permiso de consulta.
CUADRO 14. Actores.
Diagramas de Casos de Uso de ERP-Social
FIGURA 15. CASO DE USO 1.
Administrador del Módulo
Director
Empleado
Secretaria
Administrador General
Validación de Permisos
Perfil de Usuario
Inserción de Datos
Consulta/Reportes
Adminstración de Usuarios
51
Casos de Uso Control de Asistencia
FIGURA 16. CASO DE USO 2.
Especificación del Caso de Uso
ESPECIFICACION DEL CASO DE USO
CE Registrar Empleado
Tipo Secundario
Actor E
Referencia CI autentificación
Pre condición Tener acceso al sistema, estar autenticado
Pos condición Registrar un nuevo empleado
Propósito Agregar un nuevo registro
Resumen Se agrega un nuevo empleado. Se registran los datos personales.
CURSO NORMAL
Estimulo Actor Respuesta Sistema
1 Administrador ingresa al sistema para ingresar nuevo empleado
2
Sistema acoge solicitud y pide completar datos personales del empleado, CI, nombres, apellidos,dirección, departamento
3 El administrador ingresa los datos del empleado
4 El sistema recoge datos y guarda con éxito
5
El administrador para terminar con el registro solicita al empleado que ingrese su código para el ingreso
6 El sistema agrega el código, acepta y pide autorización para guardar
7 El administrador guarda la activación del código. Cierra el Sistema
Administrador general
AutentificaciónRegistraEmpleado
52
CURSO ALTERNO
Estimulo Actor Respuesta Sistema
1
Administrador ingresa al sistema para ingresar un nuevo empleado
2
Sistema acoge solicitud y pide completar los datos personales del empleado CI, nombres, apellidos, dirección, departamento
3 El Administrador ingresa los datos del empleado 4
El sistema no se encuentra disponible. No puede realizar conexión
CUADRO 15. Especificación Caso de Uso Registrar Empleado.
Generación de Reportes
FIGURA 17. CASO DE USO 3.
Usuario Autorizado
Autentificación
Consultar Horario
Generar Reporte
Consultar Nómina
Verificación Usuario/Contraseña
Ingresar Parámetros
Imprimir Reporte
53
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: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
54
Diagramas de Secuencia de ERP-Social
FIGURA 19. DIAGRAMA DE SECUENCIA AUTENTICACIÓN.
SequenceDiagram_1
4. Usuario Autentificado
3. Usuario Existente
2. Valida Usuario BD
Valida Usuario (Contraseña)
Autentificación BD
Administrador General
55
Registrar Empleado
FIGURA 20. DIAGRAMA DE SECUENCIA ADMINISTRACIÓN.
Diagrama de Actividades
FIGURA 21. DIAGRAMA DE ACTIVIDADES.
SequenceDiagram_1
8. Código Guardado
7. Código Guardado
4. Datos Guardados
3. Datos Guardados Exitosamente
6. Ingresa Código CI
5. Ingresa Código
2. Ingresa Datos Empleado
Ingresa Empleado
Persona Empleado Dirección Departamento
Administrador General
BD
56
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]
57
FIGURA 22. CICLO DE VIDA DE MVC.
FUENTE: https://miblogtecnico.wordpress.com/tag/mvc/
3.5 Diseño de la Base de Datos
3.5.1. 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.
3.5.2. 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.
58
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 PREFIJO
Empleado EMP
Estudiante EST
Departamento DEP
Provincia 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 SUFIJO
Tabla TBL, Sufijo de Módulo por ejemplo Control de Asistencia CDA.
Secuencia SEQ
Departamento DEP
Vista VW
Clave Primaria PK
Clave Única UK
Clave Foránea FK
Índice IDX
Trigger TRG
Procedimientos PRC
Funciones FUN
Paquetes PKG
CUADRO 17. Sufijos BDD.
59
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.
60
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
61
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
3.5.3. 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:
3.5.4. Diccionario de Datos
Se detalla en Anexo 3. Diccionario de Base de Datos
62
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 Informático, (Tutor).
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.
63
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.
4.3. 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
64
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:
CUADRO 19. Costos.
ITEM CantidadValor
UnitarioValor
Nº Nº $ $
0 0 0
0
Uso de equipo de la empresa Horas 0 0 0
Personal de apoyo Horas 0 0 0
0
Tutor de trabajo de graduación Horas 0 0 0
Tribunal de trabajo de graduación Horas 0 0 0
Investigador (autor de trabajo de grado) Horas 400 8 3200
3200
Impresora laser Unidad 1 150 150
Tóner Unidad 3 30 90
Flash memory Unidad 1 15 15
Copias Unidad 2000 0,03 60
315
OTROS (Gastos: agua, luz, telf.) Días 400 0,25 100
Credenciales Unidad 1 5 5
Horas Hombre Horas 291 5 1455
Transporte Días 85 1,5 127,5
Internet Meses 6 30 180
Uso de equipo personal Horas 500 0,5 250
200
3715
185,75
3900,75
ALUMNO (ÍTEM 4+5) 3900,75
1
2
3
4
5
TOTAL DEL PRESUPUESTO
FINANCIAMIENTO
UCE (ÍTEM 1+3) 0
EMPRESA (ÍTEM 2) 0
SUBTOTAL DE RECURSOS MATERIALES
SUBTOTAL OTROS
TOTAL
IMPREVISTOS (5%)
SUBTOTAL EMPRESA
RECURSOS HUMANOS
SUBTOTAL RECURSOS HUMANOS
RECURSOS MATERIALES
Material de escritorio:
RUBRO Unidad
RECURSOS INSTITUCIONALES UCE
SUBTOTAL UCE
RECURSOS EMPRESARIALES EMPRESA
Materias primas:
65
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.
66
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.
5.2. 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.
67
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.
68
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.
69
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.
70
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.
71
REFERENCIAS BIBLIOGRÁFICAS
1. Florencia Chiesa. (2004). Metodología para Selección De Sistemas ERP. Extraído
el 14 de junio de 2013 desde
http://www.ucla.edu.ve/dac/departamentos/informatica-ii/metodologia-para-
seleccion-de-sistemas-erp.PDF(pag.17)
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
http://www.uce.edu.ec/web/ingenieria-ciencias-fisicas-y-matematica.
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
http://www.uce.edu.ec/web/ingenieria-ciencias-fisicas-y-matematica.
4. Asesoría informática WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde
http://www.asesoriainformatica.com/erp_01.html
5. ¿Buscas el mejor Software ERP para tu negocio? (n.d). Extraído 19 de Julio de
2014 desde http://www.tuerp.com/g/beneficios
6. Aprender aprogramar en jav WWW user survey. (n.d). Extraído 15 de Julio de 2013
desde
http://aprenderaprogramar.com/index.php?option=com_content&view=article&id=36
8:ique-es-java-concepto-de-programacion-orientada-a-objetos-vs-programacion-
estructurada-cu00603b&catid=68:curso-aprender-programacion-java-desde-
cero&Itemid=188
7. JAVA. (n.d). Extraído 15 de Julio de 2013 desde
http://es.wikibooks.org/wiki/Programaci%C3%B3n_en_Java/Caracter%C3%ADsticas_del_len
guaje
8. BDD Extraído 25 de Agosto de 2014 desde
https://microbuffer.wordpress.com/2011/05/04/que-es-postgresql/
9. Introducción Ingeniería WWW user survey. (n.d). Extraído 15 de Julio de 2013
desde http://www.ingenieriadesoftware.mex.tl/61885_Modelo-V.html
10. Java WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde
http://www.infor.uva.es/~jmrr/tgp/java/JAVA.html
11. Posgresql WWW user survey. (n.d). Extraído 15 de Julio de 2013 desde
http://es.scribd.com/doc/36570462/postgreSQL-investigacion
12. LA PIRÁMIDE DE LA CALIDAD WWW user survey. (n.d). Extraído 15 de Julio de
2013 desde http://www.acerosarequipa.com/construccion-industrial/boletin-
construccion-integral/edicion-3/calidad.html
13. 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.
72
14. Desarrollando aplicaciones informáticas con el Proceso de Desarrollo Unificado
(RUP). (n.d). Extraído 19 de Julio de 2014 desde
http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP.
15. mindmeister (n.d). Extraído 19 de Julio de 2014 desde
https://www.mindmeister.com/es/261074538/modelo-rup.
16. requerimientos (n.d). Extraído 19 de Julio de 2014 desde
http://requerimientos.galeon.com/
17. Introducción a UML (n.d). Extraído 19 de Julio de 2014 desde
https://docs.kde.org/stable/es/kdesdk/umbrello/uml-basics.html
18. Patrón de arquitectura Modelo Vista Controlador (n.d). Extraído 19 de Julio de 2014
desde http://www.lab.inf.uc3m.es/~a0080802/RAI/mvc.html
73
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
Atributo
Tipo Nulo Descripción
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
Atributo
Tipo Nulo Descripción
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
74
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
Atributo
Tipo Nulo Descripción
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
75
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
Atributo
Tipo Nulo Descripción
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
76
Vista ASISTENCIA_EMPLEADOS
En la tabla se guardan toda la información de las Asistencias de Usuarios:
Nombre del
Atributo
Tipo Nulo Descripción
ID 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
desempeña el
usuario
FECHA_INGRES
O
Date (10) Not null Fecha en la cual
ingreso a laborar el
usuario
FECHA_ASISTE
NCIA
Date (10) Not null Fecha en que se ha
tomado la
asistencia del
Usuario
DIAS_SEMANA String (10) Not null Días las cuales el
empleado ha
asistido.
HORA_ENTRAD
A
Date (10) Not null Hora de entrada
HORA_SALIDA Date (10) Not null Hora de salida
HORARIO String (2) Not null El horario el cual
trabaja el usuario
77
ANEXO II
MANUAL DE USUARIO
Contenido
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
78
Pantalla inicial
Al ingreso a la URL del sistema se presentara la pantalla de login al sistema
URL: http://SERVIDOR/ErpSocialWeb/seguridad/login.xhtml
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.
79
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
80
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.
81
Para mostrar el menú nuevamente se utilizara el botón que se presentara en la parte superior
izquierda del área de trabajo.
Menú Control de Asistencia
82
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.
83
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:
84
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
85
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:
86
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.
87
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 , se presentara la siguiente
pantalla:
88
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.
89
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 , se desplegara la siguiente
pantalla:
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.
90
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:
91
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
92
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:
93
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
Email 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.
94
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 se
desplegara la siguiente pantalla.
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.