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
DEDICATORIA
A dios en primer lugar, segundo y la más importante a mis padres, a mi
madre Silvana por tantas noches de desvelo y por mantenerse siempre a mi
lado y nunca dejarme rendirme durante todas las etapas de la vida, a mi
padre Tarquino al que no pude darle la alegría de verme graduado pero sé
que es mi ángel en el cielo y desde ahí estará orgulloso de su hijo, ya que
con su ejemplo y enseñanzas dedico su vida a nosotros, desde aquí un
gracias padre mío.
A mi esposa quien estuvo siempre a mi lado impulsándome y dándome
fuerzas para seguir.
A mi hija que es el motor de mi vida por la que seguiré luchando siempre.
A toda mi familia por acompañarme siempre.
José Ignacio Tovar Campaña
II
AGRADECIMIENTO
A los docentes por brindarnos a los estudiantes durante el proceso de
formación el conocimiento y las herramientas necesarias para un excelente
desempeño profesional ético.
A mi Tutor Ing. César Morales, director de tesis, por su valiosa orientación en
todo momento, durante el desarrollo y culminación del proyecto de tesis.
A la prestigiosa Universidad Central del Ecuador, Facultad de Ingeniería,
Ciencias y Matemática por haberme dado la oportunidad de formarme como
profesional.
José Ignacio Tovar Campaña
III
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
IV
CERTIFICACION DEL TUTOR
V
NOTIFICACIÓN DE TRIBUNAL
VI
RESULTADO DEL TRABAJO DE GRADUACIÓN
VII
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.
2
PRESENTACIÓN DEL PROBLEMA
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
VIII
2.2.11.
2.3.
Base de Datos
18
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.
25
METODOLOGÍA.
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
Requerimientos
29
3.2
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.
62
MARCO ADMINISTRATIVO
4.1.
Recursos
62
4.2.
Recursos Institucionales
63
4.3.
Recursos del autor
63
4.4.
Costos
64
CAPITULO V
65
5.
65
Conclusiones y Recomendaciones
5.1.
Conclusiones
65
5.2.
Recomendaciones
66
GLOSARIO
67
REFERENCIAS BIBLIOGRÁFICAS
71
ANEXO I
73
ANEXO II
77
IX
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.
FIGURA 2. MODELO DE DESARROLLO.
FIGURA 3. TRIÁNGULO DE GESTIÓN DE PROYECTOS.
FIGURA 4. PIRÁMIDE DE LA CALIDAD.
FIGURA 5. CICLO DE VIDA RUP.
FIGURA 6. DIAGRAMA DE CLASES.
FIGURA 7. CLASE.
FIGURA 8. ASOCIACIÓN GENERALIZACIÓN.
FIGURA 9. ASOCIACIÓN 1-1.
FIGURA 10. ASOCIACIÓN ACUMULACIÓN.
FIGURA 11. ASOCIACIÓN COMPOSICIÓN.
FIGURA 12. CASOS DE USO.
FIGURA 13. DEFINICIÓN PERSONA-EMPLEADO.
FIGURA 14. DEFINICIÓN HORARIO.
FIGURA 15. CASO DE USO 1.
FIGURA 16. CASO DE USO 2.
FIGURA 17. CASO DE USO 3.
FIGURA 18. DIAGRAMA DE SECUENCIA.
FIGURA 19. DIAGRAMA DE SECUENCIA AUTENTICACIÓN.
FIGURA 20. DIAGRAMA DE SECUENCIA ADMINISTRACIÓN.
FIGURA 21. DIAGRAMA DE ACTIVIDADES.
FIGURA 22. CICLO DE VIDA DE MVC.
X
12
13
21
22
26
41
41
42
43
44
44
45
46
48
50
51
52
53
54
55
55
57
LISTA DE TABLAS
CUADRO 1. REQUERIMIENTO NO FUNCIONAL
CUADRO 2. REQUERIMIENTO FUNCIONAL 1.
CUADRO 3. REQUERIMIENTO FUNCIONAL 2.
CUADRO 4. REQUERIMIENTO FUNCIONAL 3.
CUADRO 5. REQUERIMIENTO FUNCIONAL 4.
CUADRO 6. REQUERIMIENTO FUNCIONAL 5.
CUADRO 7. REQUERIMIENTO FUNCIONAL 6.
CUADRO 8. REQUERIMIENTO FUNCIONAL 7.
CUADRO 9. REQUERIMIENTOS TÉCNICOS SERVIDOR.
CUADRO 10. MÉTODO INGRESAEMPLEADO.
CUADRO 11. MÉTODO CONSULTAEMPLEADO.
CUADRO 12. MÉTODO ACTUALIZAEMPLEADO.
CUADRO 13. MÉTODO INGRESARCODIGO.
CUADRO 14. ACTORES.
CUADRO 15. ESPECIFICACIÓN CASO DE USO REGISTRAR EMPLEADO.
CUADRO 16. PREFIJOS BDD.
CUADRO 17. SUFIJOS BDD.
CUADRO 18. RECURSOS.
CUADRO 19. COSTOS.
XI
30
31
32
33
34
35
36
37
38
46
47
47
48
50
52
58
58
62
64
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/ ERPSOCIAL/
VINCULACIÓN
CON
WEB/REINGENIERÍA DEL SISTEMA
XII
LA
SOCIEDAD/
SISTEMA
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/ ERPSOCIAL/
VINCULACIÓN
CON
WEB/REINGENIERÍA DEL SISTEMA
XIII
LA
SOCIEDAD/
SISTEMA
CERTIFICADO DE TRADUCCIÓN
XIV
TÍTULO
XV
INTRODUCCIÓN
En el transcurrir del tiempo la utilización de tecnología se ha hecho
preponderante en todo tipo de actividades, las aplicaciones informáticas son
parte del diario vivir y los servicios que estas prestan forman parte
importante de la vida social.
Son innumerables las actividades que dependen netamente de los medios
informáticos.
En la sociedad actual es necesario contar con sistemas informáticos que se
diversifiquen y permitan realizar varias operaciones sobre los mismos, estos
servicios son conocidos como tecnologías de la información.
Los sistemas ERP por sus siglas en ingles ENTERPRISE RESOURCE
PLANNING, son los que mayor avance tienen hoy en día ya que permiten
mantener información de varios sistemas integrados en una sola plataforma,
esto mejora la visión global de todo un proceso y permite optimizar los
procesos de negocio.
La Facultad de Ingeniería, Ciencias Físicas y Matemática, de la Universidad
Central del Ecuador, en vista de promover la automatización de procesos y
vinculación con la sociedad ha implementado en la parroquia San Pedro de
Amaguaña, del Distrito Metropolitano de Quito, el sistema ―ERP Social‖, que
administra los módulos relacionados a la gestión documental escolar y
eclesiástica.
1
CAPITULO I
1. PRESENTACIÓN DEL PROBLEMA
1.1. Planteamiento del Problema
La Facultad de Ingeniería de la Universidad Central del Ecuador, institución
de alta excelencia académica y social, durante su trayectoria ha promovido
el desarrollo del país, formando profesionales comprometidos al ―servicio de
los intereses del bienestar del pueblo ecuatoriano y el mundo.‖ [2]
Hoy en día la automatización de los procesos que se ejecutan en una
organización está basada en la implementación de sistemas informáticos, es
así, que se plantea como proyecto la ―Implementación del Sistema ―ERP
Social‖, en la Escuela de la ―Unidad Educativa Corazón de Maria‖ del cantón
Quito, provincia de Pichincha y reingeniería del sistema a nuevas
herramientas de desarrollo.
El objetivo del proyecto es la reingeniería del sistema actual a nuevas
herramientas de desarrollo y brindar a la Escuela de la ―Unidad Educativa
Corazón de Maria‖, automatizar los procesos de control de asistencia de sus
empleados.
Como antecedentes para el presente proyecto se tiene que el proyecto ―ERP
Social‖, fue implementado en la parroquia de ―Amaguaña‖ de la provincia de
Pichincha.
La reingeniería del sistema actual está basada en la constante evolución de
los sistemas informáticos, tanto en sus tecnologías como en herramientas de
desarrollo, es preciso mejorar aspectos como robustez, calidad y eficiencia,
para cumplir con las demandas de los usuarios y de los procesos de trabajo
en sí.
2
1.2. Formulación del Problema
La Escuela de la ―Unidad Educativa Corazón de Maria‖
de la parroquia
―Tumbaco ―del Cantón Quito de la provincia de Pichincha, se encuentran
desprovistas de sistemas que les permita manejar correctamente los
procesos de la gestión de asistencia de sus empleados; por lo cual los
procesos se lo realizan de forma manual, lo que consume tiempo y recursos
innecesarios que pueden ser optimizados dentro de la cada Institución.
Previo el planteamiento del proyecto se realizó un análisis en base a visitas y
entrevistas para identificar las necesidades de las instituciones.
De los resultados obtenidos se plantea la implementación del Módulo de
Control de Asistencia del sistema ERP Social, planteando así el
levantamiento y mejora de los procesos que realizan referentes al control de
asistencia en base a sus recursos tanto físicos como económicos lo cual
permitirá que el sistema se ajuste de manera exitosa a futuro en diferentes
parroquias, con una mayor efectividad en el manejo del flujo y
procesamiento de los datos y contribuirá al mejoramiento progresivo de la
comunidad y la sociedad.
La reingeniería e implementación del sistema ERP Social Modulo de Control
de Asistencia tiene como objetivo brindar a las instituciones beneficios como:

Disminución de uso de suministros de oficina.

Mantener información en línea.

Automatización de su proceso de control de asistencia.

Mejora de los procesos institucionales.
3
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.
4
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.
5
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.
6
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.
7
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.
8
2.2.
Marco Teórico
En la Escuela de la ―Unidad Educativa Corazón de Maria‖, las instituciones
educativas pertenecientes a la parroquia de Tumbaco es importante la
implementación del módulo de Control de Asistencia del sistema ERP Social
el cual permitirá la regularización y manejo de la información.
Un ERP cuya definición es sistema de Planificación de Recursos
Empresariales, son Sistemas de Información Gerenciales que integran y
manejan negocios asociados con las operaciones de producción y de los
aspectos de distribución de una compañía en la producción de bienes o
servicios.
Los
sistemas
ERP
normalmente
manejan
la
producción,
logística,
distribución, inventario, envíos, facturas y la contabilidad
en una
organización. Puede intervenir en el control de muchas actividades de
negocios como ventas, entregas, pagos, producción, administración de
inventarios, calidad de administración y la administración de recursos
humanos.
Este sistema es un sistema que trata directamente con los clientes, o con los
sistemas de negocios electrónicos tales como: comercio electrónico,
gobierno
electrónico,
telecomunicaciones
electrónicas
y
finanzas
electrónicas; así mismo, es un sistema que trata directamente con los
proveedores, no estableciendo únicamente una relación administrativa con
ellos (SRM), en contraste con el sistema de apertura de datos (front office),
que crea una relación administrativa del consumidor o servicio al
consumidor. [4]
9
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.
10
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.
11
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-ATRAVES-DEL-CICLO-DE-VIDA-DEL-SOFTWARE-I/
La parte izquierda de la V representa la corriente donde se definen las
especificaciones del sistema.
La parte derecha de la V representa la corriente donde se comprueba el
sistema (contra las especificaciones definidas en la parte izquierda).
La parte de abajo, donde se encuentran ambas partes, representa la
corriente de desarrollo.
La corriente de especificación consiste principalmente de:



Especificaciones de requerimiento de usuario
Especificaciones funcionales
Especificaciones de diseño
La corriente de pruebas, por su parte, suele consistir de:



Calificación de instalación
Calificación operacional
Calificación de rendimiento
12
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.
13

NIVEL 1 está orientado al cliente. El inicio del proyecto y el fin del
proyecto constituyen los dos extremos del ciclo. Se compone del análisis
de requisitos y especificaciones, se traduce en un documento de
requisitos y especificaciones.

NIVEL 2 se dedica a las características funcionales del sistema
propuesto. Puede considerarse el sistema como una caja negra, y
caracterizarla únicamente con aquellas funciones que son directa o
indirectamente visibles por el usuario final, se traduce en un documento
de análisis funcional.

NIVEL 3 define los componentes hardware y software del sistema final, a
cuyo conjunto se denomina arquitectura del sistema.

NIVEL 4 es la fase de implementación, en la que se desarrollan los
elementos unitarios o módulos del programa. [5]
Ventajas:

Específica bien los roles de los distintos tipos de pruebas a realizar.

Hace explícito parte de la iteración y trabajo que hay que realizar.

Este método involucra chequeos de cada una de las etapas del método
Cascada.

Es un método más robusto y completo que el método cascada y produce
software de mayor calidad que con el modelo cascada.

Es un modelo sencillo de y de fácil aprendizaje.

Involucra al usuario en las pruebas.
Desventajas:

Es difícil que el cliente exponga explícitamente todos los requisitos.

El cliente debe tener paciencia, ya que obtendrá el producto al final del
ciclo de vida.

El modelo no contempla la posibilidad de retornar etapas inmediatamente
anteriores, cosa que en la realidad puede ocurrir.
14

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
15
y C++, y dado que la mayoría de la gente los conoce aunque sea de
forma elemental, resulta muy fácil aprender Java.

Orientado al objeto
Todos los conceptos en los que se apoya esta técnica, encapsulación,
herencia, polimorfismo, etc., están presentes en Java.

Distribuido
Java proporciona una colección de clases para su uso en aplicaciones de
red, que permiten abrir sockets y establecer y aceptar conexiones con
servidores o clientes remotos, facilitando así la creación de aplicaciones
distribuidas.

Interpretado
Java es compilado, en la medida en que su código fuente se transforma
en una especie de código máquina, los Bytecodes semejantes a las
instrucciones de ensamblador. Por otra parte, es interpretado, ya que los
bytecodes se pueden ejecutar directamente sobre cualquier máquina a la
cual se hayan portado el intérprete y el sistema de ejecución en tiempo
real (run-time).

Robusto
Java fue diseñado para crear software altamente fiable. Para ello
proporciona numerosas comprobaciones en compilación y en tiempo de
ejecución. Sus características de memoria liberan a los programadores
de una familia entera de errores (la aritmética de punteros), ya que se ha
prescindido por completo de los punteros, y la recolección de basura
elimina la necesidad de liberación explícita de memoria.

Seguro
Dada la naturaleza distribuida de Java, donde las applets se bajan desde
cualquier punto de la Red, la seguridad se impuso como una necesidad
de vital importancia. A nadie le gustaría ejecutar en su ordenador
16
programas con acceso total a su sistema, procedentes de fuentes
desconocidas. Así que se implementaron barreras de seguridad en el
lenguaje y en el sistema de ejecución en tiempo real.

Arquitectura neutral.
Java está diseñado para soportar aplicaciones que serán ejecutadas en
los más variados entornos de red, desde Unix a Windows Nt, pasando
por Mac y estaciones de trabajo, sobre arquitecturas distintas y con
sistemas operativos diversos. Para acomodar requisitos de ejecución tan
diversos, el compilador de Java genera bytecodes: un formato intermedio
indiferente a la arquitectura diseñada para transportar el código
eficientemente a múltiples plataformas hardware y software. El resto de
problemas los soluciona el intérprete de Java.

Portable
La indiferencia a la arquitectura representa sólo una parte de su
portabilidad. Además, Java especifica los tamaños de sus tipos de datos
básicos y el comportamiento de sus operadores aritméticos, de manera
que los programas son iguales en todas las plataformas. Estas dos
últimas características se conocen como la Máquina Virtual Java (JVM).

Produce applets.
Java puede ser usado para crear dos tipos de programas: aplicaciones
independientes y applets. Las aplicaciones independientes se comportan
como cualquier otro programa escrito en cualquier lenguaje, como por
ejemplo el navegador de Web HotJava, escrito íntegramente en Java.
Por su parte, las applets son pequeños programas que aparecen
embebidos en las páginas Web, como aparecen los gráficos o el texto,
pero con la capacidad de ejecutar acciones muy complejas, como animar
imágenes, establecer conexiones de red, presentar menús y cuadros de
diálogo para luego emprender acciones, etc.
17

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]
18
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
19
licencia. Con PostgreSQL, nadie puede demandarlo por violar acuerdos
de licencia, puesto que no hay costo asociado a la licencia del software.

Modelos de negocios más rentables con instalaciones a gran escala.

Flexibilidad para hacer investigación y desarrollo sin necesidad de incurrir
en costos adicionales de licenciamiento.

Mejor soporte que los proveedores comerciales

Ahorros considerables en costos de operación

El software ha sido diseñado y creado para tener un mantenimiento y
ajuste mucho menor que los productos de los proveedores comerciales,
conservando todas las características, estabilidad y rendimiento. Además
de esto, nuestros programas de entrenamiento son reconocidamente
mucho más costo-efectivos, manejables y prácticos en el mundo real que
aquellos de los principales proveedores comerciales.

Estabilidad y con fiabilidad legendarias

PostgreSQL está disponible en casi cualquier Unix (34 plataformas en la
última versión estable), y una versión nativa de Windows está
actualmente en estado beta de pruebas.

PostgreSQL usa una estrategia de almacenamiento de filas llamada
MVCC para conseguir una mejor respuesta en ambientes de grandes
volúmenes. Los principales proveedores de sistemas de bases de datos
comerciales que usan también esta tecnología, por las mismas razones.
[11]
2.3.
Identificación de Variables
Las variables se identificaran en base al estudio del triángulo de la gestión
de Proyectos o conocido como el ―triángulo de hierro‖; en el cual se denota
La gestión de un proyecto, bajo el enfoque del PMI, nos dice que los
gerentes a menudo hablan de una triple restricción:
1). Cuánto va a costar el proyecto (COSTO),
2.) Cuánto va a durar el proyecto (TIEMPO),
3.) Cuáles son las características y funciones del producto y qué trabajo
debe hacerse para entregar este producto (ALCANCE). [12]
20
FIGURA 3. TRIÁNGULO DE GESTIÓN DE PROYECTOS.
Fuente: http://www.acerosarequipa.com/construccion-industrial/boletin-construccion-integral/edicion3/calidad.html

Costo: es la asignación de fondos muchas veces de una forma no
flexible, ya que es una variable dependiente no es posible fijar
exactamente la cantidad total a utilizar.

Tiempo: básicamente mide la duración del proyecto en base a los
tiempos de cada etapa del mismo.

Alcance: conjunto de características que deseamos obtener finalmente.
En el centro de este triángulo estará la calidad del resultado final, el mismo
será afectado si en cualquier lado del triángulo cambia.
Adicionalmente a estos tres factores, aparece un cuarto elemento que es la
calidad, que es la resultante del grado de cumplimiento de los otros tres
factores. Esto define el nivel de calidad.
En el tema de la calidad, al igual que en el de los alcances, también
podemos diferenciar entre lo que significa la calidad del producto y la calidad
del proceso.
21
FIGURA 4. PIRÁMIDE DE LA CALIDAD.
Fuente: http://www.acerosarequipa.com/construccion-industrial/boletin-construccion-integral/edicion3/calidad.html
La calidad del producto es relativa, ya que depende de las expectativas del
cliente. Cada perfil de cliente tiene más o menos las mismas necesidades,
pero diferentes deseos y valores (estos dos últimos son fuertemente
influenciados por agentes externos, tales como el marketing, la cultura, la
coyuntura, etc.). Por eso, cuando definimos los alcances del producto,
requerimos adecuar sus características y funciones a las expectativas y al
uso del cliente final o del mercado meta.
La calidad del proceso implica ejecutar la producción de la manera más
eficiente posible, optimizando los trabajos que generan transformación,
disminuyendo los que solamente contribuyen a ésta y tratando de eliminar
todos aquellos procesos que generan pérdidas.
Por otro lado, cuando definimos el alcance del proyecto, requerimos
especificar sólo el trabajo requerido. Esto nos permitirá controlar y
diferenciar lo que está o no está incluido en el proyecto. [13]
22
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 ERPSocial.

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.
23

Aplicar las mejores prácticas de programación para el desarrollo de
proyectos que contribuyan al avance tecnológico orientado a la sociedad.

Para lograr culminar y cumplir todos los objetivos de este proyecto es
necesario del compromiso y participación de todos los involucrados,
obteniendo como resultado un control eficaz de la asistencia de sus
empleados.
24
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
25

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.
26
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.
27
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]
28
3.2 Requerimientos
Normalmente, un tema de la Ingeniería de Software tiene diferentes
significados. De las muchas definiciones que existen para requerimiento, a
continuación se presenta la definición que aparece en el glosario de la
IEEE.
Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal.
Los requerimientos pueden dividirse en requerimientos funcionales y
requerimientos no funcionales.
29
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 El sistema debe ser intuitivo y de fácil entrenamiento
ingreso
de para los usuarios. El sistema debe presentar mensajes de
información
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.
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.
Seguridad
El sistema deberá contar con mecanismos que permitan
el registro de actividades con identificación de los
usuarios que los realizaron.
El sistema debe contar con pistas de auditoría de las
actividades que se realizan sobre el sistema.
Mantenibilidad
El sistema debe estar documentado tanto técnica como
funcionalmente.
CUADRO 1. Requerimiento no Funcional
30
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
Modulo
Unidad Educativa "Corazón de María"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Registro de Empleados
Estado
Requerimiento
Implementación
Empleados
Tipo de Requerimiento
Categoría
Complejidad
Módulos afectados
Registro
Necesario
Alta
Ninguno
Descripción
Requerimiento
de
Registro
23/05/2013
1
Definido
Alcance
de
Prioridad
Tiempo
DEV
Alta
15 días
del
Registro del Empleado
El sistema permitirá crear un nuevo empleado para llevar el control de
sus asistencia, para la creación del empleado se utilizaran datos como:
fotografía, CI, Nombres y Apellidos, Fecha de Nacimiento, Dirección,
Número Telefónico, Numero de Afiliación, Fecha de Ingreso,
Departamento, User_ID, Clave, Código de Asistencia, Estado.
Dentro de la opción de Registro de empleados el usuario tendrá la
opción de buscar los empleados por diferentes parámetros como:
Cedula de Empleado, Nombres, Apellidos.
Solución Funcional
CUADRO 2. Requerimiento Funcional 1.
31
REQUERIMIENTO
Cliente
Modulo
Unidad Educativa "Corazón de Maria"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Registro Faltas
Estado
Requerimiento
Implementación de Registro de Faltas
Tipo de Requerimiento
Categoría
Complejidad
Módulos afectados
Registro
Necesario
Alta
Ninguno
Descripción
Requerimiento
Prioridad
Tiempo
DEV
23/05/2013
2
Definido
Alcance
Alta
20 días
del
Registro de Faltas
El sistema permitirá el registro de falta de un empleado de forma
manual, el proceso de registro de falta será automático al no ingresar los
datos en la pantalla de autentificación. Para el registro manual se
contara con los campos: Empleado, fecha de la falta, descripción. en la
pantalla de registro de faltas se desplegara todas las faltas sean estas
registradas de forma manual o automática, además contara con
parámetros de búsqueda: cedula, nombres, apellidos
Solución Funcional
CUADRO 3. Requerimiento Funcional 2.
32
REQUERIMIENTO
Cliente
Modulo
Unidad Educativa "Corazón de Maria"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Parámetros
Estado
Requerimiento
Parametrizacion
Tipo de Requerimiento
Parametrizacion
Categoría
Complejidad
Módulos afectados
Necesario
Alta
Ninguno
Descripción
Requerimiento
Prioridad
Tiempo
DEV
23/05/2013
3
Definido
Alcance
Alta
20 días
del Parámetros
El sistema contara con dos parámetros que permitirán manejar las
holguras de entrada y atrasos para el módulo de asistencia.
Solución Funcional
CUADRO 4. Requerimiento Funcional 3.
33
REQUERIMIENTO
Cliente
Modulo
Unidad Educativa "Corazón de Maria"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Registro de Permiso
Estado
Requerimiento
Tipo de Requerimiento
Categoría
Complejidad
Módulos afectados
Descripción
Requerimiento
Implementación de Registro de Permisos Prioridad
Tiempo
Registro
DEV
Necesario
Alta
Ninguno
23/05/2013
4
Definido
Alcance
Alta
20 días
del
Registro de Permiso
El sistema permitirá registrar permisos/ vacaciones de un empleado con
fecha inicio y fecha fin, estas fechas a las que se asigna como permiso o
vacaciones no será tomadas en cuenta para el registro de asistencia de
un empleado.
Solución Funcional
CUADRO 5. Requerimiento Funcional 4.
34
REQUERIMIENTO
Cliente
Modulo
Unidad Educativa "Corazón de Maria"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Días Laborables
Estado
Requerimiento
Implementación de Parametrizacion de
Días Laborables
Prioridad
Tiempo
Parametrizacion
DEV
Necesario
Alta
Ninguno
Tipo de Requerimiento
Categoría
Complejidad
Módulos afectados
Descripción
Requerimiento
23/05/2013
5
Definido
Alcance
Alta
25 días
del
Días Laborables
El sistema permitirá ingresar los días no laborables para que no sean
tomas en cuenta en el registro de asistencia de los empleados. Esto se lo
realizara con un componente tipo calendario donde el usuario debe
parametrizar los días que no serán laborables, además contara con la
funcionalidad de marcado automático para fines de semana, si se desea
desmarcar un día ya marcado como no laborable el sistema lo permitirá
teniendo en cuenta que no se puede desmarcar fechas anteriores a la
actual y este cambio se lo realizara una sola vez en cada periodo.
Solución Funcional
CUADRO 6. Requerimiento Funcional 5.
35
REQUERIMIENTO
Cliente
Modulo
Unidad Educativa "Corazón de Maria"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Reportes
Estado
Implementación de Reportes
Prioridad
Tiempo
DEV
Requerimiento
Tipo de Requerimiento
Categoría
Complejidad
Módulos afectados
Descripción
Requerimiento
Reportes
Necesario
Alta
Ninguno
23/05/2013
6
Definido
Alcance
Alta
25 días
del
Reportes
El módulo de control de asistencia permitirá obtener los siguientes
reportes: FALTAS devuelve un listado de faltas por usuario con la fecha
de la falta. ATRASOS devuelve un listado de atrasos por usuario con la
fecha de cada uno de los registros. HORAS TRABAJADAS devuelve un
total de horas trabajadas en un periodo de tiempo. Todos los reportes
podrán ser exportados en formato Excel y PDF
Solución Funcional
CUADRO 7. Requerimiento Funcional 6.
36
REQUERIMIENTO
Cliente
Modulo
Unidad Educativa "Corazón de Maria"
Control de Asistencia
Fecha
Numero
Sub-Modulo
Horarios
Estado
Definición de Horarios
Prioridad
Tiempo
DEV
Requerimiento
Tipo de Requerimiento
Categoría
Complejidad
Módulos afectados
Descripción
Requerimiento
Registro
Necesario
Alta
Ninguno
23/05/2013
7
Definido
Alcance
Alta
15 días
del
Definición de Horarios
El módulo de control de asistencia para la definición de horarios contara
con dos funcionalidades: TIPO en la opción tipo se podrá definir varios
tipos de horarios esto basado en que dentro de una misma institución y
para diferentes empleados se puede tener varios horarios. DEFINICION
en esta opción se definirá hora de entrada y de salida para cada tipo de
horario, la funcionalidad permitirá definir horarios por día.
Solución Funcional
CUADRO 8. Requerimiento Funcional 7.
37
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.
38
3.3 Lenguaje de Modelamiento Unificado (UML)
El lenguaje unificado de diagrama o notación (UML) sirve para especificar,
visualizar y documentar esquemas de sistemas de software orientado a
objetos. UML no es un método de desarrollo, lo que significa que no sirve
para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino
que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible
para otros. UML está controlado por el grupo de administración de objetos
(OMG) y es el estándar de descripción de esquemas de software.
UML está diseñado para su uso con software orientado a objetos.
UML se compone de muchos elementos de esquematización que
representan las diferentes partes de un sistema de software. Los elementos
UML se utilizan para crear diagramas, que representa alguna parte o punto
de vista del sistema.
UML Modeller soporta los siguientes tipos de diagramas:
Diagrama de casos de uso: muestra a los actores (otros usuarios del
sistema), los casos de uso (las situaciones que se producen cuando utilizan
el sistema) y sus relaciones.
Diagrama de clases: muestra las clases y la relaciones entre ellas.
Diagrama de secuencia: muestra los objetos y sus múltiples relaciones
entre ellos.
Diagrama de colaboración: muestra objetos y sus relaciones, destacando
los objetos que participan en el intercambio de mensajes.
Diagrama de estado: muestra estados, cambios de estado y eventos en un
objeto o en parte del sistema.
Diagrama de actividad: muestra actividades, así como los cambios de una
a otra actividad junto con los eventos que ocurren en ciertas partes del
sistema.
Diagrama de componentes: que muestra los componentes de mayor nivel
de la programación.
Diagrama de implementación: muestra las instancias de los componentes
y sus relaciones.
39
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
principales funciones:
objetivos de UML se pueden resumir en sus
Visualizar
UML permite describir de una manera gráfica un sistema de tal forma que
sea de fácil comprensión para otras personas.
Especificar
UML permite realizar la especificación de las características a un buen nivel
del sistema a desarrollar.
Construir
UML sirve como base en el diseño para la construcción de los sistemas.
Documentar
Todos los tipos de diagramas que se elaboran basados en UML sirven como
documentación.
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]
40
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
41
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
42
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.
43
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.
44
Ejemplo
FIGURA 12. CASOS DE USO.
FUENTE: https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html#class-diagram
45
Diagramas de Clases ERP – Social: Módulo de Asistencia
Definición de Persona – Empleado
Empleado
Persona
-
Cedula
Nombres
Apellidos
Foto
Fecha
:
:
:
:
:
Direccion
- Codigo : int
int
char
char
byte
Date
+
+
+
+
IngresarEmpleado () : void
ConsultarEmp ()
: char
ActualizarEmp ()
: void
IngresarCodigo ()
: int
- Cod_Direccion : int
- Direccion
: char
+ IngresarDireccion () : void
+ Refrescar () : void
Departamento
- Cod_Depno
: int
- NombreDeptno : char
+ IngresarDeptno () : void
FIGURA 13. DEFINICIÓN PERSONA-EMPLEADO.
Método IngresaEmpleado
Nombre
Public
void
codigo,deptno)
Responsabilidad
Permite registrar al empleado en la base de datos para crear
después el control de asistencia
Sistema
Registro Empleado
Registro Empleado
Si no existe CI del empleado está equivocado
Confirma que los datos se ingresaron en la base de datos
El sistema reconoce la autentificación
Tipo
Referencia Cruzada
Notas
Excepciones
Salida
Precondiciones
IngresarDocente(CI,nombres,apellidos,foto,fecha,
POSCONDICIONES
Se crea una instancia para IngresaEmpleaado
Los datos fueron guardados exitosamente en el sistema
CUADRO 10. Método IngresaEmpleado.
46
Método ConsultaEmpleado
Nombre
Public void ConsultarEmpleado(CI, cod_Control)
Responsabilidad
Tipo
Referencia Cruzada
Notas
Excepciones
Salida
Precondiciones
Permite consultar el registro de asistencia del docente en la
base de datos
Sistema
RegistraEmpleado
Utilizar índices para la consulta
No exista el CI, del empleado, indicar que no es posible
encontrar Historial
Confirma que los datos son encontrados
El sistema reconoce la autentificación
POSCONDICIONES
Se crea una instancia para buscar datos de Empleado
El sistema muestra los datos encontrados quedando en condiciones de revisión
para el administrador general exitosamente en el sistema
CUADRO 11. Método ConsultaEmpleado.
Método ActualizaEmpleado
Nombre
Public void ActualizaEmpleado(CE)
Responsabilidad
Permite actualizar el registro del empleado
Tipo
Sistema
Referencia
Cruzada
RegistraEmpleado
Notas
Utilizar índices para la consulta
Excepciones
No exista el CE o está equivocado. No se pueden actualizar los datos
Salida
Precondiciones
Confirma que los datos se actualizaron exitosamente en la base
de datos
El sistema reconoce la autentificación
POSCONDICIONES
Se crea una instancia para actualizar datos de Empleado
El sistema muestra los datos de empleado actualizados
CUADRO 12. Método ActualizaEmpleado.
47
Método IngresarCodigo
Nombre
Public void IngresarCodigo(CE)
Responsabilidad
Permite registrar el código de empleado en la base de datos
Tipo
Sistema
Referencia
Cruzada
RegistraEmpleado
Notas
Excepciones
No exista el CE o está equivocado. No se pueden registrar código
Salida
Precondiciones
Confirma que el código fue ingresado exitosamente en la base
de datos
El sistema reconoce la autentificación
POSCONDICIONES
Se crea una instancia para ingreso de código del empleado
El sistema muestra los datos de empleado y el código ingresado recientemente
CUADRO 13. Método IngresarCodigo.
Definición de Horario
Horario
0..1
- Nombre : char
- Hora
: int
- Estado : char
0..1
+ Insertar (char nombre) () : char
+ buscar (char nombre) () : char
+ actualizar ()
: void
0..*
0..*
Año Lectivo
Holgura
- Ingreso : int
- Salida : int
- Descripcion : char
- Estado
: boolean
- Fecha
: Date
+ Insertar () : char
+ Editar () : char
+ Buscar () : char
+ Buscar () : char
+ Insertar () : char
+ Editar () : char
FIGURA 14. DEFINICIÓN HORARIO.
48
Caso de uso
Un caso de uso describe, —desde el punto de vista de los actores—, un
grupo de actividades de un sistema que produce un resultado concreto y
tangible.
Los casos de uso son descriptores de las interacciones típicas entre los
usuarios de un sistema y ese mismo sistema. Representan el interfaz
externo del sistema y especifican qué requisitos de funcionamiento debe
tener este.
Cuando se trabaja con casos de uso, es importante tener presentes algunas
reglas:



Cada caso de uso está relacionado como mínimo con un actor
Cada caso de uso es un iniciador (es decir, un actor)
Cada caso de uso lleva a un resultado relevante (un resultado con
«valor intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres
tipos de relaciones más comunes entre casos de uso son:
Include: especifica una situación en la que un caso de uso tiene lugar dentro
de otro caso de uso
Extends: especifica que en ciertas situaciones, o en algún punto (llamado
punto de extensión) un caso de uso será extendido por otro.
Generalización: especifica que un caso de uso hereda las características
del (súper) caso de uso, y puede volver a especificar algunas o todas ellas
de una forma muy similar a las herencias entre clases.
Actor
Un actor es una entidad externa (de fuera del sistema) que interacciona con
el sistema participando (y normalmente iniciando) en un caso de uso. Los
actores pueden ser gente real (por ejemplo, usuarios del sistema), otros
ordenadores o eventos externos.
Los actores no representan a personas físicas o a sistemas, sino su rol. Esto
significa que cuando una persona interactúa con el sistema de diferentes
maneras (asumiendo diferentes papeles), estará representado por varios
actores. [17]
49
Identificación de actores de ERP-Social
Actor
Actividades
Administrador General
Persona encargada de administrar las actividades, gestión y
mantenimiento del ERP
Persona
encargada
de
la
gestión
y
mantenimiento del módulo a su cargo
Administrador
Módulo
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
Usuario Registrado
Persona delegada para dicho cargo en la institución
Sus permiso son de consulta e inserción de datos, sin embargo puede
ser una delegada del administrador del sistema.
Persona con permiso de consulta.
CUADRO 14. Actores.
Diagramas de Casos de Uso de ERP-Social
Administrador del Módulo
Inserción de Datos
Validación de Permisos
Director
Consulta/Reportes
Perfil de Usuario
Empleado
Secretaria
Adminstración de Usuarios
Administrador General
FIGURA 15. CASO DE USO 1.
50
Casos de Uso Control de Asistencia
Autentificación
RegistraEmpleado
Administrador general
FIGURA 16. CASO DE USO 2.
Especificación del Caso de Uso
ESPECIFICACION DEL CASO DE USO
CE
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
1
3
5
7
Respuesta Sistema
Sistema acoge solicitud y pide
completar
2 datos personales del empleado, CI,
Administrador
ingresa
al
sistema
nombres,
apellidos,dirección,
para ingresar nuevo empleado
departamento
El administrador ingresa los datos del
El sistema recoge datos y guarda con
4
empleado
éxito
El administrador para terminar con el
registro
El sistema agrega el código, acepta y
6
solicita al empleado que ingrese su código
pide
para el ingreso
autorización para guardar
El administrador guarda la activación del
código.
Cierra el Sistema
51
CURSO ALTERNO
Estimulo Actor
1
3
Respuesta Sistema
Administrador ingresa al sistema para
ingresar
un nuevo empleado
Sistema acoge solicitud y pide completar
los datos personales del empleado CI, nombres,
2 apellidos, dirección, departamento
El Administrador ingresa los datos del
El sistema no se encuentra
empleado
4 No puede realizar conexión
CUADRO 15. Especificación Caso de Uso Registrar Empleado.
Generación de Reportes
Autentificación
Verificación Usuario/Contraseña
Consultar Horario
Ingresar Parámetros
Usuario Autorizado
Generar Reporte
Imprimir Reporte
Consultar Nómina
FIGURA 17. CASO DE USO 3.
52
disponible.
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
53
Diagramas de Secuencia de ERP-Social
SequenceDiagram_1
Autentificación
BD
Administrador General
Valida Usuario (Contraseña)
2. Valida Usuario BD
3. Usuario Existente
4. Usuario Autentificado
FIGURA 19. DIAGRAMA DE SECUENCIA AUTENTICACIÓN.
54
Registrar Empleado
SequenceDiagram_1
Persona
Empleado
Dirección
Departamento
Administrador General
Ingresa Empleado
2. Ingresa Datos Empleado
3. Datos Guardados Exitosamente
4. Datos Guardados
5. Ingresa Código
6. Ingresa Código CI
7. Código Guardado
8. Código Guardado
FIGURA 20. DIAGRAMA DE SECUENCIA ADMINISTRACIÓN.
Diagrama de Actividades
FIGURA 21. DIAGRAMA DE ACTIVIDADES.
55
BD
3.4 Arquitectura Modelo-Vista-Controlador
El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que
define la organización independiente del Modelo (Objetos de Negocio), la
Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del
workflow de la aplicación).
De esta forma, dividimos el sistema en tres capas donde tenemos la
encapsulación de los datos, la interfaz o vista y la lógica interna o
controlador.
El patrón de arquitectura "modelo vista controlador", es una filosofía de
diseño de aplicaciones, compuesta por:
Modelo



Contiene el núcleo de la funcionalidad (dominio) de la aplicación.
Encapsula el estado de la aplicación.
No sabe nada / independiente del Controlador y la Vista.
Vista



Es la presentación del Modelo.
Puede acceder al Modelo pero nunca cambiar su estado.
Puede ser notificada cuando hay un cambio de estado en el Modelo.
Controlador

Reacciona a la petición del Cliente, ejecutando la acción adecuada y
creando el modelo pertinente.
Para entender cómo funciona nuestro patrón Modelo vista controlador, se
debe entender la división a través del conjunto de estos tres elementos.
Comunicación
En el modelo, la vista y el controlador deben comunicarse de una manera
estable los unos con los otros, de manera que sea coherente con las
iteraciones que el usuario realizara. [18]
56
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.
57

No deben contener espacios en blanco, de ser necesaria la
separación de palabras se debe utilizar un guión bajo.
Prefijos
Todo objeto de la base de datos debe utilizar un prefijo estándar que permita
relacionarlo con la aplicación, mismo que corresponderá a las tres primeras
letras del nombre del módulo.
Ejemplo
OBJETO
Empleado
Estudiante
Departamento
Provincia
PREFIJO
EMP
EST
DEP
PRO
CUADRO 16. Prefijos BDD.
Sufijos
Todo objeto de la base de datos debe utilizar un sufijo estándar que permita
identificar el tipo de objeto al que corresponde. El sufijo será el siguiente
dependiendo del tipo de objeto:
Ejemplo
TIPO DE OBJETO
Tabla
Secuencia
Departamento
Vista
Clave Primaria
Clave Única
Clave Foránea
Índice
Trigger
Procedimientos
Funciones
Paquetes
SUFIJO
TBL, Sufijo de Módulo por
ejemplo
Control
de
Asistencia CDA.
SEQ
DEP
VW
PK
UK
FK
IDX
TRG
PRC
FUN
PKG
CUADRO 17. Sufijos BDD.
58
Nombres de Objetos
Al nombrar cualquier objeto, no se debe escatimar en colocar un nombre
largo, lo importante es que sea claro y descriptivo.
Cuando se trata de nombres compuestos por más de una palabra, se deben
eliminar las conjunciones, preposiciones y artículos.
Se debe además utilizar el formato COMPLEMENTO-OBJETO-ACCIÓN; en
caso de que el nombre no tuviere acción, utilizar el formato
COMPLEMENTO-OBJETO.
Ejemplos:
Transacciones = TRANSACCIONES
Detalle de Transacciones = DETALLE_TRANSACCIONES
Si el nombre de un objeto excede los 30 caracteres, su tamaño debe ser
reducido manteniendo el mismo lo más descriptivo posible hasta completar
los 30 caracteres, utilizando el mejor criterio del desarrollador. Para reducir
los nombres de los objetos se recomienda aplicar lo siguiente:




Si se trata de nombres compuestos de más de una palabra, utilizar las
palabras más significativas del mismo.
Utilizar abreviaturas estándar.
Desde la izquierda del nombre se puede remover las vocales excepto
la primera letra de la palabra en caso de que esta sea una vocal.
La unión entre el prefijo, el nombre del objeto y el sufijo, se lo hace
por medio de un guión bajo.
Campos de Tablas
Para nombrar los campos de las tablas se deben tener en cuenta las
siguientes consideraciones:



El nombre de un campo debe ser único dentro del esquema en el que
se encuentra.
El nombre de un campo debe ser expresado utilizando palabras
completas y debe ser lo más descriptivo posible.
El nombre de cada campo tendrá un prefijo compuesto por los dos
primeros caracteres del nombre de la tabla si este es una sola
palabra. Si el nombre de la tabla es compuesto, se utilizará como
prefijo el primer carácter de las dos primeras palabras
respectivamente.
59
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,
EMP_INGRESOS_DETALLLE_FK
60
será:
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
IMP_INGRESOS_VW
se
obtiene
la
vista:
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
61
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
Debe estar en capacidad de tomar
Director o Presidente de la 1 o
decisiones para la institución a
Institución
2
cargo.
Informático, Conocimientos relacionados
1
con el proyecto.
Debe pertenecer a la institución y
será el responsable de la gestión
del proyecto.
Ingeniero Informático o
Conocimientos relacionados
relacionado,
2
con el proyecto.
(Revisores).
Debe pertenecer a la institución y
se encargará de la revisión del
documento y cumplimiento de
tiempos establecidos.
Análisis, diseño y desarrollo
1
de aplicaciones web.
Estudiante
de
Ingeniería
Informática de la Universidad
Central del Ecuador que no pase
los dos años de egresado.
Ingeniero
(Tutor).
Tesista (Desarrollador)
CUADRO 18. Recursos.
62
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
63
4.4.
Costos
Para la elaboración, desarrollo e implementación del presente proyecto el autor
cubrirá los costos directos e indirectos que deriven hasta la finalización del
proyecto.
El análisis de costos se lo realizo en base a la siguiente tabla:
ITEM
RUBRO
Valor
Unitario
Valor
Nº
$
$
0
0
0
Unidad
Nº
1
Cantidad
RECURSOS INSTITUCIONALES UCE
SUBTOTAL UCE
0
RECURSOS EMPRESARIALES EMPRESA
2
Materias primas:
Uso de equipo de la empresa
Horas
0
0
0
Personal de apoyo
Horas
0
0
0
SUBTOTAL EMPRESA
0
RECURSOS HUMANOS
3
Tutor de trabajo de graduación
Horas
0
0
Tribunal de trabajo de graduación
Investigador (autor de trabajo de grado)
Horas
0
0
0
Horas
400
8
3200
SUBTOTAL RECURSOS HUMANOS
0
3200
RECURSOS MATERIALES
Material de escritorio:
4
Impresora laser
Unidad
1
150
150
Tóner
Unidad
3
30
90
Flash memory
Unidad
1
15
15
Copias
Unidad
2000
0,03
60
Días
400
0,25
100
Credenciales
Unidad
1
5
5
Horas Hombre
Horas
291
5
1455
Días
85
1,5
127,5
Meses
6
30
180
Horas
500
0,5
250
SUBTOTAL DE RECURSOS MATERIALES
315
OTROS (Gastos: agua, luz, telf.)
5
Transporte
Internet
Uso de equipo personal
SUBTOTAL OTROS
200
TOTAL
3715
IMPREVISTOS (5%)
185,75
TOTAL DEL PRESUPUESTO
3900,75
FINANCIAMIENTO
UCE (ÍTEM 1+3)
0
EMPRESA (ÍTEM 2)
0
ALUMNO (ÍTEM 4+5)
3900,75
CUADRO 19. Costos.
64
CAPITULO V
5. Conclusiones y Recomendaciones
Una vez finalizado el proyecto de graduación en el que se cumplió con todos
los objetivos planteados para el desarrollo de la implementación y
reingeniería del sistema ERP Social se han generado las siguientes
conclusiones y recomendaciones en base a lo desarrollado:
5.1.
Conclusiones
Terminada la implementación del módulo Control de Asistencia en la
Escuela de la ―Unidad Educativa Corazón de Maria‖ se obtuvieron las
siguientes conclusiones.

La parametrizacion, el cambio de herramientas de desarrollo y el
cambio de la planificación incidieron directamente en los costos del
presente proyecto.

La implementación de un sistema Web en instituciones públicas
permite mejorar sus servicios y ahorrar tanto en costos como en
tiempos para la ejecución de sus procesos.

Mediante la reingeniería del sistema ERP Social a nuevas tecnologías
de desarrollo como es JAVA ha permitido obtener como producto final
un sistema más amigable, robusto y permite a las instituciones
acceder a su información de manera Online.

La implementación del sistema ERP Social modulo Control de
Asistencia automatiza un proceso que se llevaba de forma manual en
la institución.

La utilización del leguaje UML permitió al desarrollador entender de
una manera más clara y explícita la lógica de lo que el usuario
especifico en los requerimientos iniciales.

El soporte primordial sobre el cual se sustenta un sistema ERP es la
lógica de negocio y el diseño de la BDD que es la raíz de la
organización de los datos de cada institución.

En la práctica se puede evidenciar que con la implantación del módulo
de Control de Asistencia se ha reducido el tiempo de ejecución de
este proceso en las diferentes instituciones.
65

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.
66
GLOSARIO
A
Array: En programación, es una zona de almacenamiento continuo, que
contiene una serie de elementos del mismo tipo. Desde el punto de vista
lógico se puede ver como un conjunto de elementos ordenados en fila.
B
BSD: en español, ―Distribución de Software Berkeley‖ fue un sistema
operativo derivado del sistema Unix nacido a partir de los aportes realizados
a ese sistema por la Universidad de California en Berkeley.
Bytecode: es un código intermedio más abstracto que el código máquina.
Habitualmente es tratado como un archivo binario que contiene un programa
ejecutable similar a un módulo objeto, que es un archivo binario producido
por el compilador cuyo contenido es el código objeto o código máquina.
D
Dialéctica: es el nombre que recibe aquella parte de la Filosofía que se
ocupa del razonamiento y de las leyes de éste, las formas y las maneras de
expresarse.
Digitalización: convertir en digital información analógica. Es convertir
cualquier señal de entrada continua (analógica) en una serie de valores
numéricos.
Por ejemplo, una fotografía en papel puede digitalizarse para que pueda ser
procesada en una computadora (u otro dispositivo similar). La información
digital es la única información que puede procesar una computadora,
generalmente en sistema binario.
E
E-learning: es la educación a distancia completamente virtualizado a través
de los nuevos canales electrónicos (las nuevas redes de comunicación, en
especial Internet), utilizando para ello herramientas o aplicaciones de
hipertexto (correo electrónico, páginas web, foros de discusión, mensajería
instantánea) como soporte de los procesos de enseñanza-aprendizaje.
ERP: Sistemas de Información Gerenciales que integran y manejan
negocios asociados con las operaciones de producción y de los aspectos de
distribución de una compañía en la producción de bienes o servicios.
67
F
FTP: ―File Transfer Protocol‖; en español 'Protocolo de Transferencia de
Archivos', es un protocolo de red para la transferencia de archivos entre
sistemas conectados a una red TCP (Transmission Control Protocol),
basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede
conectar a un servidor para descargar archivos desde él o para enviarle
archivos, independientemente del sistema operativo utilizado en cada
equipo.
H
HTML: (HyperText Markup Language); en español ―lenguaje de marcas de
hipertexto‖, hace referencia al lenguaje de marcado para la elaboración de
páginas web. Es un estándar que sirve de referencia para la elaboración de
páginas web en sus diferentes versiones, define una estructura básica y un
código (denominado código HTML) para la definición de contenido de una
página web, como texto, imágenes, entre otros.
HTTP: HyperText Transfer Protocol; en español ―Protocolo de transferencia
de hipertexto‖ es el método más común de intercambio de información en la
world wide web, el método mediante el cual se transfieren las páginas web a
un ordenador.
J
JSF: JavaServer Faces es una tecnología y framework para aplicaciones
Java basadas en web que simplifica el desarrollo de interfaces de usuario en
aplicaciones Java EE. JSF usa JavaServer Pages (JSP) como la tecnología
que permite hacer el despliegue de las páginas, pero también se puede
acomodar a otras tecnologías
L
Logística: conjunto de medios y métodos necesarios para llevar a cabo la
organización de una empresa, o de un servicio, especialmente de
distribución.
M
Migración: consiste en la transferencia de materiales digitales de un origen
de datos a otro, transformando la forma lógica del ente digital de modo que
el objeto conceptual pueda ser restituido o presentado por un nuevo equipo
o programa informático. Se trata de una consideración clave para cualquier
implementación, actualización o consolidación de un sistema informático.
68
Módulo: es una porción de un programa de computadora. De las varias
tareas que debe realizar un programa para cumplir con su función u
objetivos, un módulo realizará, comúnmente, una de dichas tareas.
MVC: es un patrón de arquitectura de software que separa los datos y la
lógica de negocio de una aplicación de la interfaz de usuario y el módulo
encargado de gestionar los eventos y las comunicaciones. Para ello MVC
propone la construcción de tres componentes distintos que son el modelo, la
vista y el controlador, es decir, por un lado define componentes para la
representación de la información, y por otro lado para la interacción del
usuario. Se basa en las ideas de reutilización de código y la separación de
conceptos, características que buscan facilitar la tarea de desarrollo de
aplicaciones y su posterior mantenimiento.
O
Optimizar: Buscar la mejor manera de realizar una actividad.
P
PGDG: PostgreSQL Global Development Group, comunidad de
desarrolladores que trabajan de forma desinteresada, altruista, libre y/o
apoyados por organizaciones comerciales en el proyecto PostgreSQL.
Premisas: es cada una de las proposiciones anteriores a la conclusión de
un argumento. En un argumento válido, las premisas implican la conclusión,
pero esto no es necesario para que una proposición sea una premisa: lo
único relevante es su lugar en el argumento, no su rol. Al ser proposiciones,
las premisas siempre afirman o niegan algo y pueden ser verdaderas o
falsas.
R
Reingeniería: Es el rediseño de un proceso en un negocio o un cambio
drástico de un proceso. Recupera información sobre el diseño de un
programa existente, con vistas a adaptarlo a un cambio, a ampliarlo o a
mejorar su calidad general, con el objetivo de conseguir una mayor facilidad
de mantenimiento en el futuro.
Requerimiento: En ingeniería del software y el desarrollo de sistemas, un
requerimiento es una necesidad documentada sobre el contenido, forma o
funcionalidad de un producto o servicio. Los requerimientos son
declaraciones que identifican atributos, capacidades o características y/o
cualidades que necesita cumplir un sistema para que tenga valor y utilidad
para el usuario.
69
RollBack: En tecnologías de base de datos, un rollback es una operación
que devuelve a la base de datos a algún estado previo. Los Rollbacks son
importantes para la integridad de la base de datos, a causa de que significan
que la base de datos puede ser restaurada a una copia limpia incluso
después de que se han realizado operaciones erróneas. Son cruciales para
la recuperación de crashes de un servidor de base de datos; realizando
rollback (devuelto) cualquier transacción que estuviera activa en el tiempo
del crash, la base de datos es restaurada a un estado consistente.
V
Versatilidad: Facilidad grande para el cambio, sobre todo de genio o
carácter.
70
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-paraseleccion-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-programacionestructurada-cu00603b&catid=68:curso-aprender-programacion-java-desdecero&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
https://microbuffer.wordpress.com/2011/05/04/que-es-postgresql/
desde
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
http://www.infor.uva.es/~jmrr/tgp/java/JAVA.html
de Julio de 2013
desde
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/boletinconstruccion-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.
71
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
https://www.mindmeister.com/es/261074538/modelo-rup.
de
2014
desde
16. requerimientos
(n.d).
Extraído
http://requerimientos.galeon.com/
de
2014
desde
19
de
Julio
17. Introducción a UML (n.d). Extraído 19 de Julio
https://docs.kde.org/stable/es/kdesdk/umbrello/uml-basics.html
de
2014
desde
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
72
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
Atributo
CODIGO
del Tipo
Nulo
Descripción
Integer
Not null
NOMBRE
String (20)
Not null
CONTRASEÑA
Integer (10)
Not null
Código
del
Administrador
Nombre
del
Administrador
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
Atributo
CODIGO
del Tipo
Nulo
Descripción
Integer
Not null
NOMBRE
String (20)
Not null
CONTRASEÑA
Integer (10)
Not null
Código
del
Administrador
Nombre
del
Administrador
Contraseña
del
Administrador
para el acceso
73
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
Atributo
CODIGO
del Tipo
Nulo
Descripción
Integer
Not null
CEDULA
Integer (20)
Not null
NOMBRES
String (10)
Not null
APELLIDOS
DIRECCIÓN
String (10)
Date (10)
Not null
Not null
TELFONO_CELL
Integer(03)
Not null
TELEFONOS
Integer (20)
Not null
SEXO
AREA
String (20)
String (30)
Not null
Not null
FECHA_INGRES
O
Date (10)
Not null
Código de los
Usuarios
Cedula de los
Usuarios
Nombre de los
Usuarios
completos
Apellidos Usuarios
Direcciones de los
Usuarios para su
ubicación
Codigo del celular
para Usuarios
Teléfonos de los
Usuarios
para
contactarlo
Sexo de Usuarios
Area en la cual se
desempeña
o
Administran
los
Usuarios
Fecha en la cual
ingreso a laborar
los Usuarios
74
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
Atributo
CODIGO
del Tipo
Nulo
Descripción
Integer
Not null
CEDULA
Integer (20)
Not null
NOMBRES
String (10)
Not null
APELLIDOS
String (10)
Not null
DIRECCIÓN
Date (10)
Not null
TELEFONO_CE
L
Integer(03)
Not null
TELEFONOS
Integer (20)
Not null
SEXO
String (20)
Not null
FECHA_INGRES
O
Date (10)
Not null
Código de los
Administradores
Cedula de los
Administradores
Nombre de los
Administradores
completos
Apellidos
Administradores
Dirección
de
Administradores
Codigo del celular
para
Administradores
Teléfonos de los
Administradores
Sexo
de
Administradores
Fecha en la cual
ingreso
a
gestionar
el
Administrador
75
Vista ASISTENCIA_EMPLEADOS
En la tabla se guardan toda la información de las Asistencias de Usuarios:
Nombre
Atributo
ID
del Tipo
Nulo
Descripción
IntegerContador(3)
Not null
CODIGO
Integer (10)
Not null
CEDULA
Integer (20)
Not null
NOMBRES
String (10)
Not null
APELLIDOS
String (10)
Not null
DIRECCIÓN
Date (10)
Not null
TELEFONOS
Integer (20)
Not null
SEXO
String (20)
Not null
AREA
String (30)
Not null
FECHA_INGRES
O
Date (10)
Not null
FECHA_ASISTE
NCIA
Date (10)
Not null
DIAS_SEMANA
String (10)
Not null
HORA_ENTRAD
A
HORA_SALIDA
HORARIO
Date (10)
Not null
Identificador
y
secuenciador para
la repetición de las
asistencias
Código de los
Usuarios
Cedula
de
Usuarios
Nombre
Empleados
Apellidos de los
Usuarios
Dirección de los
Usuarios
Teléfonos de los
Usuarios
Sexo
de
los
Usuarios
Área en la cual se
desempeña
el
usuario
Fecha en la cual
ingreso a laborar el
usuario
Fecha en que se ha
tomado
la
asistencia
del
Usuario
Días las cuales el
empleado
ha
asistido.
Hora de entrada
Date (10)
String (2)
Not null
Not null
76
Hora de salida
El horario el cual
trabaja el usuario
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
77
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.
78
Si la clave no es correcta se presentara el siguiente mensaje al usuario
Si el usuario y la clave ingresados son correctos se permitirá el acceso al sistema
Cabecera
79
En cabecera se encontraran las siguientes opciones:
Inicio: redirige a la página principal
Ayuda: permite un link a los manuales del sistema.
Cerrar Sesión: permite culminar la sesión del usuario logueado
Adicionalmente se presentaran:
Empresa: corresponde a la empresa a la que pertenece el usuario logueado.
Usuario: nombre del usuario logueado.
Menú
En la cabecera del menú se presentara el botón
el
cual permite la utilización de la función menú colapsable, esto permite ocultar el menú y visualizar el
área de trabajo de una mejor forma.
80
Para mostrar el menú nuevamente se utilizara el botón
izquierda del área de trabajo.
Menú Control de Asistencia
81
que se presentara en la parte superior
Reporte de horas Trabajadas
Este reporte presentara la información de las horas trabajadas por usuario.
Refrescar: permite la actualización de la información que se presenta en pantalla.
Parámetros de búsqueda
Fecha: permite realizar la búsqueda por fechas.
Código Empleado: permite realizar la búsqueda por el código del empleado.
Nombres Empleado: permite realizar la búsqueda por el nombre de empleados.
Apellidos Empleados: permite realizar la búsqueda por apellidos de los empleados.
Buscar: permite ejecutar la búsqueda.
Si no se ingresa ninguno de los parámetros de búsqueda el sistema de volverá todos los registros de
los que dispone.
Resultados
#: Número de ítem que devuelve el sistema.
Cedula Empleado: número de cedula del empleado del que se devuelve el registro.
82
Apellidos Empleado: apellidos del empleado del que se devuelve el registro.
Nombres Empleado: nombres del empleado del que se devuelve el registro.
Opciones: permite visualizar todos los registros asociados al usuario que devuelve el registro.
Al dar clic sobre la opción
se desplegara la siguiente pantalla:
El registro presentara la hora de ingreso, la hora de salida y el total de horas trabajas por ítem.
Este reporte puede ser exportado en dos formatos Excel y PDF desde las opciones:
83
Reporte de Faltas
El reporte de faltas permite obtener un listado de usuarios con las fechas en las que el sistema ha
registrado una inasistencia a sus labores, se debe tener en cuenta que el sistema registra como falta
si el empleado se registra luego de la holgura permitida para atrasos.
Este reporte puede ser exportado a formato Excel y PDF desde la opción:
Para realizar la búsqueda se puede utilizar varios parámetros como:



Cedula Empleado
Nombres de Empleado
Apellido Empleado
Los resultados del reporte contiene la siguiente información:





Cedula de Empleado
Nombre de Empleado
Apellido Empleado
Dirección Empleado
Fecha
84
Reporte de Atrasos
Esta opción permite obtener un listado de atrasos por cada usuario, en el que presenta el listado por
cada registro.
Para realizar la búsqueda se puede utilizar varios parámetros como:



Cedula Empleado
Nombres de Empleado
Apellido Empleado
Los resultados del reporte contiene la siguiente información:






Cedula de Empleado
Nombre de Empleado
Apellido Empleado
Dirección Empleado
Fecha nacimiento
Opciones
Al dar clic en el botón
se despliega la siguiente pantalla:
85
Aquí se presenta la hora de entrada y hora de salida para el registro de atraso.
Este reporte es posible exportarlo a formato Excel y PDF desde la opción:
Definición de día Laboral
En esta opción el usuario administrador podrá definir en un catálogo tipo calendario las fechas de días
no laborables, el sistema presenta la opción de calendarizar por defecto todos los sábados y domingos
como días no laborables.
Nota: se debe tener en cuenta que una vez realizada la parametrizacion de los días no laborables no
es posible cambiar para el año presente.
Para definir una fecha como día no laboral se debe dar doble clic sobre el dia y se presentara la
siguiente pantalla.
En el campo observación se debe ingresar la razón por la que se marca como día no laborable, al dar
clic el sistema registra como día no laborable.
86
Registro de Permisos
Esta opción permitir registrar las fechas en las cuales el sistema no tomara como inasistencias a un
empleado, el registro de permisos permite ingresar una fecha específica, también se la puede utilizar
para registrar los días de vacaciones de los empleados.
Para realizar la búsqueda se puede utilizar varios parámetros como:



Cedula Empleado
Nombres de Empleado
Apellido Empleado
Los resultados del reporte contiene la siguiente información:




Cedula de Empleado
Nombre de Empleado
Apellido Empleado
Fecha
Para registrar un permiso se debe dar clic en la opción
pantalla:
87
, se presentara la siguiente
En el campo Empleado Permiso se registra el nombre del empleado al que se está signando el
permiso.
En el campo Fecha permiso se desplegara el componente calendario en el cual se debe marcar la
fecha de permiso.
Para guardar el nuevo registro se debe dar clic en el botón
Definición de tipos de horarios
Esta opción permite crear varios tipos de horarios, ya que las instituciones pueden tener varios
horarios para diferentes empleados, aquí solo se crea el tipo que luego será utilizado en la definición
de los horarios.
88
Al dar clic sobre la opción
se desplegar ala siguiente pantalla:
Esta opción permite modificar un registro ingresado.
Para ingresar un nuevo registro se debe dar clic en el botón
pantalla:
, se desplegara la siguiente
En el campo descripción tipo se debe ingresar el identificativo del tipo de horario que se desea crear.
Para guardar los cambios se debe dar clic sobre el botón
Parámetros de Ingreso
Esta opción permite definir la holgura para el registro de atraso y falta, la formula aplicada por el
sistema para el registro es la siguiente:
Hora de ingreso-2 horas hasta hora de ingreso = sistema registra como a tiempo.
Hora de ingreso hasta hora de ingreso + holgura = sistema registra como atraso.
Hora de ingreso + holgura en adelante el sistema registra como falta.
El valor del parámetro se lo ingresara en números y será medido en minutos.
El parámetro será creado por defecto y solo será modificable su valor para cada institución.
89
Registro manual de Faltas
Esta opción permite al usuario ingresar de forma manual un registro de falta.
Para registrar una falta de forma manual se debe dar clic en el botón
Se desplegara la siguiente pantalla:
90
En el campo Empleado Falta se registrara el nombre del empleado.
En el campo Fecha Falta se desplegara el componente tipo calendario para escoger la fecha de
asignación del registro.
Registro de nuevo empleado
Esta opción permite inscribir un nuevo empleado de la empresa para el registro de asistencia.
Para realizar la búsqueda se puede utilizar varios parámetros como:



Cedula Empleado
Nombres de Empleado
Apellido Empleado
Los resultados del reporte contiene la siguiente información:






Nombres
Apellidos
Identificación
Dirección
Fecha de nacimiento
Opciones
91
Al dar clic sobre el botón
se desplegara la siguiente pantalla para actualización de datos del
empleado escogido del listado de registros presentados.
Para ingresar un nuevo empleado para el sistema de control de asistencia se debe dar clic en el botón
, se desplegara la siguiente pantalla:
92
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.
93
Definición de horarios
Esta opción permite definir los horarios por tipo, la definición de los horarios permite discriminar por
día hora de entrada y de salida para cada tipo de horario.
Para realizar la búsqueda de los parámetros de horario se utiliza el tipo de horario.
Para insertar los parámetros de un tipo de horario se debe dar clic en el botón
desplegara la siguiente pantalla.
Tipo: lista desplegable donde se presentara los tipos de horario ingresados.
Día: lista desplegable donde se presentara los días de la semana.
Hora de Inicio: lista desplegable donde se escoge el horario de ingreso.
Hora de Salida: lista desplegable donde se escoge el horario de salida.
94
se

¿Cómo implementar - AccionERP

Cto Madrid Clubes media Maratón - Federación de Atletismo de

REQUERIMIENTOS TÉCNICO ADMINISTRATIVOS POR TIPO DE

Álgebra lineal Abril 25, 2015 Soluciones parcial 3[B] 1. (i) Los

Java Server Faces Inicio: 28 de Marzo Horario

Manual de Instalación “La Granja de Neri”

CATALOGO FORMATIVO_MDD_SEPE_Ene

(Ciudad) ( Fecha) Señores CMA CGM COLOMBIA SAS Ciudad

valor total contratación de la institución que reporta

Requisitos para la firma electrónica en este Ministerio

MANUAL TECNICO DEL PORTAL RTM