Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
I
Departamento De Computacio n
Tí tulo del trabajo:
Autor del trabajo:
Tutores del trabajo:
, Junio 2018
“Sistema de Información para la Planificación y Control de la Guardia Obrero-
Estudiantil en la UCLV”.
Yorda n La zaro Lo pez Ferna ndez
Lic. Iasmany Ortega Sanabria
MSc. Juan Carlos Ortega Camacho
II
Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu”
de Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria
“Chiqui Go mez Lubian” subordinada a la Direccio n de Informacio n Cientí fico Te cnica
de la mencionada casa de altos estudios.
Se autoriza su utilizacio n bajo la licencia siguiente:
Atribución- No Comercial- Compartir Igual
Para cualquier informacio n contacte con:
Direccio n de Informacio n Cientí fico Te cnica. Universidad Central “Marta Abreu” de
Las Villas. Carretera a Camajuaní . Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830
Tele fonos: +53 01 42281503-1419
III
El que suscribe Yordán Lázaro López Fernández, hago constar que el trabajo titulado
Sistema de Información para la Planificación y Control de la Guardia Obrero-Estudiantil
en la UCLV fue realizado en la Universidad Central “Marta Abreu” de Las Villas como
parte de la culminación de los estudios de la especialidad de Ingeniería Informática,
autorizando a que el mismo sea utilizado por la institución, para los fines que estime
conveniente, tanto de forma parcial como total y que además no podrá ser presentado en
eventos ni publicado sin la autorización de la Universidad.
______________________
Firma del Autor
Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos
de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un
trabajo de esta envergadura referido a la temática señalada.
____________________________ ___________________________
Firma del Tutor Firma del Jefe del Laboratorio
IV
Pensamiento
“…aquí está una de las tareas de la juventud:
empujar, dirigir con el ejemplo la producción del
hombre de mañana. Y en esta producción, en esta
dirección, está comprendida la producción de si
mismos…”
Ernesto Che Guevara
V
Dedicatoria
El desarrollo de este trabajo está dedicado a toda mi familia que de una forma u otra,
me ayudaron a terminar mi especialidad en los años que la llevo estudiando.
A todos mis amigos y profesores, por el tiempo compartido.
GRACIAS.
VI
Agradecimientos
A toda mi familia por el apoyo brindado.
A mi otra familia que me criaron desde chiquitico.
A mis tutores Iasmany y Ortega por su dedicación e interés en el trabajo.
A mi oponente Yaimara por su dedicación e interés en el trabajo.
A todos mis amigos del aula, a los de 4to año de mi especialidad y a todos aquellos
que me conocen en beca.
A todos muchas gracias.
VII
Resumen
La planificación y control de la guardia obrera estudiantil (GOE) juega un papel
fundamental en la UCLV, este proceso en todas las áreas universitarias se realiza de
forma manual. El presente trabajo se basa en la obtención de una herramienta
informática que permita la automatización de la planificación y el control de la GOE,
facilitándole de esta manera al personal encargado la realización de estas tareas. La
herramienta desarrollada muestra una interfaz agradable y un desempeño eficiente,
permitiéndole conocer a estudiantes y trabajadores sus planificaciones, así como sus
ausencias, o cualquier otra información relacionada.
VIII
Abstract
The planning and control of the student labor guard (GOE) plays a fundamental role in
the UCLV, this process in all university areas is done manually. The present work is
based on the obtaining of a computer tool that allows the automation of the planning and
control of the GOE, thus facilitating the personnel in charge of carrying out these tasks.
The tool developed shows a pleasant interface and an efficient performance, allowing
you to know students and workers their plans, as well as their absences, or any other
related information.
IX
Índice
Índice .......................................................................................................................... IX
Índice de Ilustraciones .............................................................................................. XI
Índice de Tablas ........................................................................................................ XII
Introducción ................................................................................................................ 1
Antecedentes .............................................................................................................. 2
Problema Investigación .............................................................................................. 2
Objetivo general .......................................................................................................... 2
Objetivos específicos ................................................................................................. 2
Preguntas de investigación: ...................................................................................... 2
Estructura del documento .......................................................................................... 3
Capítulo I. Fundamentación teórica .......................................................................... 4
1.1. Objetivos estratégicos de la organización. ....................................................................... 4
1.2. Objeto de estudio ............................................................................................................. 4
1.2.1. Flujo Actual de Procesos ............................................................................................. 5
1.2.2. Análisis crítico de la ejecución de los procesos ........................................................... 6
1.2.3. Procesos objeto de automatización ............................................................................ 6
1.3. Tendencias y Tecnologías Actuales .................................................................................... 7
1.3.1. Fundamentación de la Metodología utilizada............................................................. 7
1.3.2. Fundamentación del Entorno de Desarrollo, Lenguaje, Gestor de Base de Datos y
Tecnología utilizados. .......................................................................................................... 10
1.4. Conclusiones Parciales ..................................................................................................... 22
Capítulo II. Modelación del Negocio y Estimación ................................................. 23
2.1 Modelo del negocio actual ............................................................................................. 23
2.2 Reglas del negocio a considerar ..................................................................................... 23
2.3 Actores del negocio ........................................................................................................ 24
2.4 Trabajadores del negocio ............................................................................................... 24
2.5 Diagrama de casos de uso del negocio .......................................................................... 25
2.6 Actores del sistema a automatizar ................................................................................. 25
2.7 Definición de los requisitos funcionales ......................................................................... 26
2.8 Definición de los requisitos no funcionales .................................................................... 33
X
2.9 Casos de Uso del Sistema ............................................................................................... 34
2.10 Casos de uso del Sistema (Significativos) ....................................................................... 38
2.11 Descripción de los casos de uso del Sistema .................................................................. 38
2.12 Planificación basada en uno de los métodos de estimación .......................................... 46
2.12.1 Cálculo de puntos de casos de uso sin ajustar. ........................................................ 46
2.12.2 Cálculo de puntos de Casos de Uso ajustados. ........................................................ 48
2.12.3 Esfuerzo horas-hombre (E) ....................................................................................... 50
2.12.4 Estimación del esfuerzo del proyecto ...................................................................... 50
2.12.5 Cálculo del esfuerzo total ......................................................................................... 51
2.12.6 Cálculo del tiempo de desarrollo ............................................................................. 51
2.12.7 Cálculo del costo ...................................................................................................... 51
2.13 Conclusiones Parciales ................................................................................................... 51
Capítulo III. Descripción de la propuesta de solución ........................................... 52
3.1 Arquitectura del Sistema ................................................................................................ 52
3.2 Diagrama de clases de diseño ........................................................................................ 53
3.3 Diagrama de secuencia................................................................................................... 55
3.4 Tratamiento de errores .................................................................................................. 56
3.5 Integración con LDAP ..................................................................................................... 57
3.6 Diseño de la base de datos ......................................................................................... 57
3.6.1 Modelo conceptual de datos .................................................................................... 57
3.6.2 Modelo físico de datos .............................................................................................. 58
3.7 Modelo de componentes y diagrama de despliegue ..................................................... 59
3.8 Conclusiones Parciales ................................................................................................... 61
Capítulo IV. Pruebas ................................................................................................. 62
4.1 Casos de Pruebas (caja negra) ........................................................................................ 62
4.1.1 Pruebas de caja negra en casos de uso. .................................................................... 62
4.2 Plan de pruebas de rendimiento .................................................................................... 66
4.3 Conclusiones parciales del capítulo .................................................................................. 67
Conclusiones ............................................................................................................ 68
Recomendaciones .................................................................................................... 69
Bibliografía ................................................................................................................ 70
Anexos....................................................................................................................... 72
XI
Índice de Ilustraciones Ilustración 1.1 Diagrama De Actividades: Proceso Planificar. (Visual Paradigm for UML 10.1) ... 6
Ilustración 1.2: Evolución de RUP. (Fernández, 2010) .................................................................. 7
Ilustración 1.3: Fases de RUP. (Fernández, 2010) ......................................................................... 9
Ilustración 1.4: Marcas de HTML. (Murcia, 2011) ....................................................................... 11
Ilustración 1.5: Componentes de un estilo CSS básico. (Javier Eguiluz Pérez, 2008) .................. 12
Ilustración 1.6: Estructura de los archivos de bootstrap. (Wikipedia, 2018) .............................. 13
Ilustración 1.7: Servidor y Cliente MySQL. (Mysql, no date) ....................................................... 20
Ilustración 1.8: Escritorio y Cliente MySQL junto a un Servidor MySQL. (Mysql, no date) ......... 20
Ilustración 1.9: Escritorio, Cliente MySQL y Servidor MySQL. (Mysql, no date) ......................... 20
Ilustración 1.10: UML. (Fernández, 2010) ................................................................................... 21
Ilustración 1.11: Vistas y diagramas de UML. (James Rumbaugh, Ivar Jaconson, 1999) ............ 22
Ilustración 2.1: Diagrama de Casos de Uso del Negocio. (Visual Paradigm for UML 10.1) ........ 25
Ilustración 2.2: Diagrama de Casos de Uso del Sistema Actor Jefe Departamento
Administrativo. (Visual Paradigm for UML 10.1)......................................................................... 35
Ilustración 2.3: Diagrama de Casos de Uso del Sistema Actor Responsable de la planificación y
control. (Visual Paradigm for UML 10.1) ..................................................................................... 36
Ilustración 2.4: Diagrama de Casos de Uso del Sistema Actor Jefe de Comisión. (Visual
Paradigm for UML 10.1) .............................................................................................................. 36
Ilustración 2.5: Diagrama de Casos de Uso del Sistema Actores UCLV. (Visual Paradigm for UML
10.1) ............................................................................................................................................ 37
Ilustración 2.6: Diagrama de Casos de Uso del Sistema Actor Administrador. (Visual Paradigm
for UML 10.1) .............................................................................................................................. 37
Ilustración 2.7: Diagrama de Casos de Uso del Sistema Actores Estudiante-Trabajador. (Visual
Paradigm for UML 10.1) .............................................................................................................. 37
Ilustración 3.1: El patrón Modelo Vista Controlador. (Alvarez, 2014) ........................................ 52
Ilustración 3.2: Diagrama de clase de Planificación. (Visual Paradigm for UML 10.1) ................ 54
Ilustración 3.3: Diagrama de clase de Ausencia. (Visual Paradigm for UML 10.1)...................... 54
Ilustración 3.4: Diagrama de secuencia de Panificación. (Visual Paradigm for UML 10.1) ......... 55
Ilustración 3.5: Diagrama de secuencia de Ausencia. (Visual Paradigm for UML 10.1) .............. 56
Ilustración 3.6: Validación JQuery plugin. (Informativa, 2016) ................................................... 56
Ilustración 3.7: Modelo Conceptual de Datos. (Embarcadero ERStudio 8.0) ............................. 58
Ilustración 3.8: Modelo Físico de Datos. (Embarcadero ERStudio 8.0) ....................................... 59
Ilustración 3.9: Diagrama de Componentes Gestionar Planificación. (Visual Paradigm for UML
10.1) ............................................................................................................................................ 60
Ilustración 3.10: Diagrama de Componentes Gestionar Ausencia. (Visual Paradigm for UML
10.1) ............................................................................................................................................ 60
Ilustración 3.11: Diagrama de Despliegue. (Visual Paradigm for UML 10.1) .............................. 61
Ilustración 4.1: Adicionar nuevo estudiante. (Elaboración Propia) ............................................ 63
Ilustración 4.2: Prueba de Carga. (Apache-Jmeter-2.6) .............................................................. 66
Ilustración 4.3: Prueba de Stress. (Apache-Jmeter-2.6) .............................................................. 67
Ilustración 4.4: Prueba de Rendimiento. (Apache-Jmeter-2.6) .................................................. 67
XII
Índice de Tablas Tabla 2.1: Actores del Negocio. ................................................................................................... 24
Tabla 2.2: Trabajadores del negocio. .......................................................................................... 24
Tabla 2.3: Actores del Sistema. ................................................................................................... 26
Tabla 2.4: Descripción del caso de uso Planificación. ................................................................. 42
Tabla 2.5: Descripción del caso de uso Ausencias. ..................................................................... 46
Tabla 2.6: Factor de Peso de los Actores sin ajustar. .................................................................. 47
Tabla 2.7: Factor de Peso de los Casos de Uso sin ajustar. ......................................................... 47
Tabla 2.8: Factor de complejidad técnica. .................................................................................. 49
Tabla 2.9: Factor de ambiente. ................................................................................................... 49
Tabla 2.10: Distribución genérica del esfuerzo. .......................................................................... 50
Tabla 2.11: Esfuerzo Calculado. .................................................................................................. 50
Tabla 4.1: Clasificación de las condiciones de entrada. (Gestionar Estudiantes - adicionar) ..... 64
Tabla 4.2: Juegos de datos. (Gestionar Estudiantes - adicionar) ................................................ 65
1
Introducción Los sistemas de la educación superior y en particular las universidades, están
experimentando cambios importantes en todo el mundo. Estos cambios según (García,
2008) tienen que ver con sus dimensiones sustantivas, esto es, con lo académico, cuyo
nivel de calidad se trata de preservar o mejorar. En países como Estados Unidos, Gran
Bretaña, Francia y España, la gestión está hoy experimentando profundos cambios en
cuanto a la forma de autoridad o gobierno, los mecanismos de financiamiento y las
modalidades que asumen en cada caso la evaluación de la calidad. Aunque sobresalen
por su importancia, estas no son desde luego las únicas dimensiones de la gestión,
habrá que tener presente que, a nivel institucional, importa también la gestión de los
asuntos académicos, de los sistemas de información, del personal, de la investigación,
etc.
Las universidades en Cuba conjugan las actividades científico-docentes y científico-
investigativas, lo que resulta una condición indispensable para la elevación de la calidad
de la educación superior. La adecuada valoración del papel de las actividades científico-
tecnológicas (ACT) repercute positivamente en la preparación de los profesionales y en
la pertinencia social de la institución, ofreciendo resultados de impacto social,
económico y cultural a la sociedad.
Los cambios de acuerdo con (Medina Basso, 2008) en el modo de hacer de las
universidades conducen a una profunda transformación cualitativa que se experimenta
en la actualidad, y en tal sentido, el Ministerio de Educación Superior (MES) se ha
incorporado con alta prioridad a la tarea de obtener.
En Villa Clara, la UCLV como parte del proceso de mejora continua, comienza a
introducir e implementar herramientas tecnológicas más potentes para el procesamiento
de la información proveniente de las diferentes áreas para la toma de decisiones.
En la UCLV y en particular en las facultades o direcciones no existe una herramienta
para la planificación y control de la GOE. Con el objetivo de buscar una solución a esta
problemática se implementa un nuevo sistema acorde con las nuevas necesidades
tecnológicas en el proceso de informatizar los procesos universitarios.
Como resultado del estudio bibliográfico se obtuvo una solución práctica para la gestión
de la GOE, lo que es de vital importancia para el perfeccionamiento en las condiciones
actuales en que se desarrolla la Educación Superior en Cuba y en particular en la UCLV.
2
Antecedentes El único antecedente de este proyecto en la UCLV es la realización de una práctica
laboral en 3er año de Ingeniería Informática, además se realizó por otro grupo de
estudiantes un proyecto para subir nota en la asignatura “Programación Web Avanzada”
que se imparte en 4to año de esta carrera.
Problema Investigación La situación descrita anteriormente, conduce al siguiente Problema De Investigación:
¿Cómo contribuir a la automatización de la planificación y el control de la GOE en la
UCLV?
Objetivo general • Desarrollar un sistema de información para la gestión de los procesos
administrativos de planificación y control de la GOE en la UCLV.
Objetivos específicos • Analizar el estado actual de la gestión de los procesos administrativos de la
planificación y el control de la GOE en la UCLV.
• Diseñar e implementar una base de datos que facilite la gestión de los procesos
administrativos de la GOE en la UCLV.
• Implementar una aplicación web para el acceso y manejo de los datos por parte
de los estudiantes y trabajadores.
• Realizar pruebas de software y análisis de factibilidad.
Preguntas de investigación: • ¿Cómo entrevistar al cliente para definir los requisitos funcionales del negocio?
• ¿Cómo diseñar un modelo lógico de una base de datos que permita la captura
de toda la información?
• ¿Qué tecnologías seleccionar para desarrollar el software de un sitio web?
• ¿Qué gestor de base de datos seleccionar para facilitar los procesos
administrativos en la UCLV?
• ¿Cómo realizar un análisis de factibilidad mediante la aplicación de pruebas que
permitan probar cada una de sus funcionalidades?
3
Estructura del documento Este documento está estructurado en 4 capítulos, además de las conclusiones,
recomendaciones, referencias bibliográficas, anexos y observaciones.
Capítulo 1. Fundamentación teórica: Se abordan los aspectos teóricos que se deben
conocer para la presente investigación, se analizan los objetos de estudio, los sistemas
automatizados existentes vinculados al campo de acción, la fundamentación de los
objetivos, y las tendencias y tecnologías actuales.
Capítulo 2. Modelo de Negocio y Estimación: En este capítulo se describe el modelo
de negocio actual, así como las reglas de negocio a considerar, los trabajadores del
negocio, los actores del sistema a automatizar, las definiciones de los requisitos
funcionales y no funcionales, el paquete y sus relaciones y el diagrama de casos de uso
del sistema, se hace una descripción de los casos de uso más significativos y el análisis
de factibilidad al sistema desarrollado.
Capítulo 3. Descripción de la propuesta de solución: En este capítulo se describe
de forma general el funcionamiento de la aplicación, además quedan definidos la
arquitectura del sistema, el diagrama de clases y el de secuencia de los casos de usos
más significativos, los principios del diseño, el tratamiento de errores, el diseño de la
base de datos, el modelo de componentes y el diagrama de despliegue.
Capítulo 4. Prueba: En este capítulo se incluyen los resultados obtenidos al realizar las
pruebas de software como son, pruebas de caja negra y pruebas de rendimiento.
4
Capítulo I. Fundamentación teórica
En este capítulo se exponen aspectos generales para el desarrollo de la planificación y
el control de la GOE en las áreas universitarias. Se realiza un acercamiento a las formas
de planificar de algunas facultades y las metodologías utilizadas para realizar este
proceso en la facultad de Matemática, Física y Computación.
Asimismo, se exponen las tecnologías utilizadas en el desarrollo de la investigación y
algunas ideas que fundamentan las decisiones tomadas.
1.1. Objetivos estratégicos de la organización.
La Dirección de Defensa y Seguridad (DDS) de la Universidad Central “Marta
Abreu” de Las Villas está compuesta por tres grupos de seguridad interna los
cuales son:
1. Sede Central.
2. Sede Félix Valera.
3. Sede Manuel Fajardo.
Esta se encarga de dar a conocer los planes especiales y el reglamento aprobado
para cada facultad, así como la Resolución 176 de la Ley No. 1371 del 27 de
noviembre de 1971, que se refiere a la aplicación de la política de seguridad y
protección física en las instalaciones y demás bienes sociales asignados a los
organismos y entidades estatales, así como los de las organizaciones sociales y
de masas.
Se estudiaron los casos de las facultades de Ciencias Sociales, Humanidades,
Mecánica-Industrial, Química-Farmacia, Ingeniería Eléctrica y Matemática, Física
y Computación.
Esta última, es la facultad que se ha tomado como referencia tras la investigación
de su forma de planificar la GOE, que tributa al cumplimiento del objetivo de la
DDS, mediante la correcta planificación y control de la guardia y la preparación
previa de todos los estudiantes y trabajadores involucrados.
1.2. Objeto de estudio
El objeto de estudio es aquello que queremos saber sobre algún tema o situación,
también llamado fenómeno de interés. Surge de alguna inquietud o problemática,
ya sea propia o ajena (Bautista, 2012).
5
Elementos del diseño metodológico del objeto de estudio:
• Propósito.
• Enfoque.
• Dimensión temporal.
• Unidad de análisis.
• Recolección de datos.
• Tratamiento de datos.
1.2.1. Flujo Actual de Procesos
Actualmente el proceso de la planificación de la GOE se inicia con la
selección de los estudiantes y trabajadores que están físicamente aptos para
su ejecución. En el caso de los estudiantes se dividen en dos grandes
grupos: Diurno y Nocturno; los trabajadores se dividen en tres grupos: Oficial
de Guardia de Facultad Diurno (OGFD), Oficial de Guardia de Facultad
Nocturno (OGFN) y Trabajador Diurno (TD).
A los estudiantes del grupo Diurno se les asignan los tres primeros turnos
del día:
• Turno 1: 7:00 am a 11:00 am
• Turno 2: 11:00 am a 3:00 pm
• Turno 3: 3:00 pm a 7:00 pm
, a razón de dos por turno, principalmente los fines de semana, rotándose
así sus guardias en los diferentes meses.
A los estudiantes del grupo Nocturno se les asignan los tres últimos turnos:
• Turno 4: 6:30 pm a 10:00 pm
• Turno 5: 10:00 pm a 2:30 pm
• Turno 6: 3:00 am a 7:00 pm
, a razón de dos por turno en un día fijo cada mes, el orden de la distribución
que se sigue va de los años terminales hacia los iniciales.
A los OGFD, que son los encargados de que se realice la guardia de la
manera establecida según el plan (en caso de ausencias deben cubrir los
turnos según necesidad), se les asignan sus días de guardia los fines de
semana.
A los OGFN, que son los encargados de notificar y recordar a los estudiantes
la fecha a fin de garantizar la correcta ejecución de la guardia, se les asigna
un día fijo en el mes, para todo el curso escolar.
6
A los TD se les asignan los días que les toca su guardia en el curso escolar,
generalmente los fines de semana y cuando se necesite por algunas
situaciones excepcionales tales como días feriados y fenómenos naturales.
Ilustración 1.1 Diagrama De Actividades: Proceso Planificar. (Visual Paradigm for
UML 10.1)
1.2.2. Análisis crítico de la ejecución de los procesos
Partiendo del análisis del flujo actual del proceso se detectan los siguientes
problemas:
1. La realización de estas tareas se hace mediante el uso de herramientas
como Word y Excel, que no ofrecen suficientes facilidades para el
proceso de planificación y control.
2. La incorrecta escritura de algunos campos en los reportes elaborados.
3. No se garantiza la consistencia durante el almacenaje de los datos.
4. No se cuenta con una herramienta eficaz para el análisis y la toma de
decisiones.
Teniendo en cuenta lo antes planteado es que se toma la decisión de
elaborar un sistema para la gestión de la GOE de las áreas universitarias de
la UCLV.
1.2.3. Procesos objeto de automatización
Teniendo en cuenta el trabajo a realizar por el encargado de la guardia de
cada facultad de la UCLV se decide automatizar los siguientes procesos:
7
1. Planificación y control de la guardia obrera estudiantil.
2. Elaboración de los reportes de control de las guardias.
1.3. Tendencias y Tecnologías Actuales
1.3.1. Fundamentación de la Metodología utilizada.
1.3.1.1. RUP (Rational Unified Process)
Este es un proceso de software desarrollado por la empresa
Rational Software, actualmente propiedad de IBM. Junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología
estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos.
Objetivos de RUP (Fernández, 2010):
• Proporcionar una guía del orden de las actividades de los
equipos.
• Especificar cuándo y cuáles artefactos deben ser
desarrollados.
• Dirigir las tareas de desarrolladores individuales y equipos
como una sola.
• Ofrecer criterios para monitorear y medir los productos y
actividades del proyecto.
Ilustración 1.2: Evolución de RUP. (Fernández, 2010)
8
RUP en cada una de sus fases realiza una serie de artefactos que
permiten comprender mejor tanto el análisis como el diseño del
sistema entre otros.
Está conformado por 4 fases:
• Inicio: En la fase de inicio es realizada una descripción del
producto final a partir del análisis del negocio para el producto. En
esta fase se debe obtener: un modelo de casos de uso que
contenga los casos de uso más críticos, se identifican los riesgos,
se planifica la fase de elaboración y se realiza una estimación del
proyecto.
• Elaboración: El propósito de la fase de elaboración es analizar el
dominio del problema, establecer los cimientos de la arquitectura,
desarrollar el plan del proyecto y eliminar los mayores riesgos. En
esta fase se construye un prototipo de la arquitectura, que debe
evolucionar en iteraciones sucesivas hasta convertirse en el
sistema final. Este prototipo debe contener los casos de uso
críticos identificados en la fase de inicio.
• Construcción: Durante esta fase todas los componentes,
características y requisitos, que no lo hayan sido, han de ser
implementados e integrados, obteniéndose una versión del
producto que se pueda poner en manos de los usuarios (versión
beta).
• Transición: La finalidad de la fase de transición es poner el
producto en manos de los usuarios finales, para lo que
típicamente se requerirá desarrollar nuevas versiones
actualizadas del producto, completar la documentación, entrenar
al usuario en el manejo del producto, y abordar en general tareas
relacionadas con el ajuste, configuración, instalación y usabilidad
del producto.
9
Ilustración 1.3: Fases de RUP. (Fernández, 2010)
Esta metodología comprende 3 principios claves:
1. Dirigido por casos de uso: La razón de ser de un sistema es
servir a los usuarios ya sean humanos u otros sistemas; un caso
de uso es una facilidad que el sistema debe proveer a sus
usuarios. Estos constituyen la guía fundamental establecida para
las actividades a realizar durante todo el proceso de desarrollo,
incluyendo el diseño, la implementación y las pruebas del sistema.
Los casos de uso representan los requisitos funcionales del
sistema.
2. Centrado en arquitectura: La arquitectura involucra los
elementos más significativos del sistema y está influenciada entre
otros por plataformas de software, sistemas operativos,
manejadores de bases de datos, protocolos, consideraciones de
desarrollo como sistemas heredados y requisitos no funcionales.
3. Iterativo e Incremental: Para hacer más manejable un proyecto
se recomienda dividirlo en ciclos, para cada ciclo se establecen
fases de referencia, cada una de las cuales debe ser considerada
como un mini proyecto, cuyo núcleo fundamental está constituido
por una o más iteraciones de las actividades principales básicas
de cualquier proceso de desarrollo.
10
1.3.2. Fundamentación del Entorno de Desarrollo, Lenguaje, Gestor de
Base de Datos y Tecnología utilizados.
1.3.2.1. HTML
Siglas en inglés de HyperText Markup Language (lenguaje de
marcas de hipertexto), hace referencia al lenguaje de marcado
para la elaboración de páginas web.
HTML es un lenguaje que se utiliza para la creación de páginas
web. Por página entendemos el documento que aparece en el
visualizador o navegador. (Murcia, 2011)
HTML se compone de una serie de comandos, queson
interpretados por el visualizador, o programa que utilizamos para
navegar por el “World Wide Web” (WWW). En última instancia es
el visualizador el que ejecuta todas las órdenes contenidas en el
código HTML, de forma que un visualizador puede estar
capacitado para unas prestaciones, pero no para otras. Así,
podremos especificar que una página tenga una imagen de fondo,
o un texto parpadeando, pero si nuestro visualizador no está
capacitado paraesas funciones, no podremos verlas.
Sin embargo, a lo largo de sus diferentes versiones, se han
incorporado y suprimido diversas características, con el fin de
hacerlo más eficiente y facilitar el desarrollo de páginas web
compatibles con distintos navegadores y plataformas
(Computadoras de escritorio, portátiles, teléfonos inteligentes,
tabletas etc.).
Marcas y atributos.
El lenguaje HTML se estructura utilizando marcas, etiquetas o
comandos (a partir de ahorautilizaremos indistintamente uno de
estos 3 términos para denominar a los elementos en que se
estructura HTML). La forma general de unamarca es la de un
comando HTML encerrado entre dos signos de menor y mayor
como a continuación se muestra:
<marca [atributos]> ......................................[</marca>]
11
Ilustración 1.4: Marcas de HTML. (Murcia, 2011)
1.3.2.2. CSS3
CSS (Javier Eguiluz Pérez, 2008), siglas en inglés de “Cascading
Stylesheets” es un lenguaje de hojas de estilos creado para
controlar el aspecto o presentación de los documentos
electrónicos definidos con HTML. CSS es la mejor forma de
separar los contenidos de su presentación y es imprescindible
para crear páginas web complejas.
Separar la definición de los contenidos y la definición de su
aspecto presenta numerosas ventajas, ya que obliga a crear
documentos HTML bien definidos y con significado completo
(también llamados "documentos semánticos"). Además, mejora la
accesibilidad del documento, reduce la complejidad de su
mantenimiento y permite visualizar el mismo documento en
infinidad de dispositivos diferentes.
El lenguaje CSS se utiliza para definir el aspecto de todos los
contenidos, es decir, el color, tamaño y tipo de letra de los párrafos
de texto, la separación entre titulares y párrafos, la tabulación con
la que se muestran los elementos de una lista, etc.
Existen tres opciones para incluir CSS en un documento HTML.
1. Incluir CSS en el mismo documento HTML
2. Definir CSS en un archivo externo
3. Incluir CSS en los elementos HTML
CSS define una serie de términos que permiten describir cada una
de las partes que componen los estilos CSS.
12
El siguiente esquema muestra las partes que forman un estilo
CSS muy básico:
Ilustración 1.5: Componentes de un estilo CSS básico. (Javier Eguiluz
Pérez, 2008)
Características:
• Complementariedad con documentos estructurados.
• Independencia del vendedor, la plataforma y el dispositivo.
• Mantenibilidad.
• Simplicidad.
• Rendimiento de la red.
• Flexibilidad.
• Riqueza.
• Combinación con lenguajes alternativos.
• Accesibilidad.
1.3.2.3. Bootstrap Framework
Bootstrap es una plataforma web o conjunto de herramientas de
código abierto para diseño de sitios y aplicaciones web. Contiene
plantillas de diseño con tipografía, formularios, botones, cuadros,
menús de navegación y otros elementos de diseño basado en
HTML y CSS, así como, extensiones de JavaScript opcionales.
(Wikipedia, 2018)
Bootstrap fue desarrollado por Mark Otto y Jacob Thornton de
Twitter, como un ambiente integrado para fomentar la
consistencia entre las herramientas internas.
13
Características:
• Tiene un soporte relativamente incompleto para HTML5 y CSS
3, pero es compatible con la mayoría de los navegadores web.
• La información básica de compatibilidad de sitios web o
aplicaciones está disponible para todos los dispositivos y
navegadores.
• Soporta diseños web adaptables.
• Es de código abierto.
Ilustración 1.6: Estructura de los archivos de bootstrap. (Wikipedia,
2018)
Sistema de cuadrilla y diseño sensible:
Bootstrap viene con una disposición de cuadrilla estándar de
940 píxeles de ancho. Alternativamente, el desarrollador puede
usar un diseño de ancho-variable. Para ambos casos, la
herramienta tiene cuatro variaciones para hacer uso de distintas
resoluciones y tipos de dispositivos: teléfonos móviles, formato de
retrato y paisaje, tabletas y computadoras con baja y alta
resolución (pantalla ancha). Esto ajusta el ancho de las columnas
automáticamente.
La hoja de estilo CSS:
Proporciona un conjunto de hojas de estilo que proveen
definiciones básicas de estilo para todos los componentes de
HTML, esto otorga una uniformidad al navegador y al sistema de
anchura y da una apariencia moderna para el formateo de los
elementos de texto, tablas y formularios.
14
Componentes reusables:
En adición a los elementos regulares de HTML, Bootstrap
contiene otra interfaz de elementos comúnmente usados que
incluye botones con características avanzadas, etiquetas,
capacidades avanzadas de miniaturas tipográficas, formatos para
mensajes de alerta y barras de progreso.
Plugins de JavaScript:
Los componentes de JavaScript para Bootstrap están basados en
la biblioteca jQuery de JavaScript. Los plugins se encuentran en
la herramienta de plugin de jQuery. Proveen elementos
adicionales de interfaz de usuario como diálogos, tooltips y
carruseles. También extienden la funcionalidad de algunos
elementos de interfaz existentes, incluyendo por ejemplo una
función de auto-completar para campos de entrada.
1.3.2.4. JAVASCRIPT
JavaScript es un lenguaje interpretado usado para múltiples
propósitos pero solo considerado como un complemento hasta
ahora. Una de las innovaciones que ayudó a cambiar el modo en
que vemos JavaScript fue el desarrollo de nuevos motores de
interpretación, creados para acelerar el procesamiento de código.
La clave de los motores más exitosos fue transformar el código
JavaScript en código máquina para lograr velocidades de
ejecución similares a aquellas encontradas en aplicaciones de
escritorio. Esta mejorada capacidad permitió superar viejas
limitaciones de rendimiento y confirmar el lenguaje JavaScript
como la mejor opción para la web. (Gauchat, 2012)
Para aprovechar esta prometedora plataforma de trabajo ofrecida
por los nuevos navegadores, JavaScript fue expandido en relación
a su portabilidad e integración. A la vez, interfaces de
programación de aplicaciones (APIs) fueron incorporadas por
defecto en cada navegador para asistir al lenguaje en funciones
elementales. Estas nuevas APIs (como Web Storage, Canvas, y
otras) son interfaces por bibliotecas incluidas en navegadores.
15
La idea es hacer disponible poderosas funciones a través de
técnicas de programación sencillas y estándares, expandiendo el
alcance del lenguaje y facilitando la creación de programas útiles
para la web.
1.3.2.5. JQuery
JQuery es una plataforma que se basa en JavaScript, no es un
lenguaje en sí mismo. Es posible escribir jQuery con apenas
conocimiento de JavaScript, pero no es algo recomendable. Si se
desea ser capaz de escribir con confianza los complementos de
jQuery para un sitio, o modificarlos complementos que otros
escribieron, se debe familiarizar con los conceptos básicos de
JavaScript. (Franklin, Jack; Devlin, 2013)
1.3.2.6. PHP
PHP (HyperText Preprocessor) es un lenguaje "open source"
interpretado de alto nivel embebido en páginas HTML y ejecutado
en el servidor. (Bakken, Stig Saether; Aulbach, Alexander;
Schmid, Egon; Winstead, Jim; Torben, Lars Wilson; Lerdorf,
Rasmus; Zmievski, Andrei; Ahto, 2002)
PHP puede hacer cualquier cosa que se pueda hacer con un
script, procesar la información de formularios, generar páginas
con contenidos dinámicos, o mandar y recibir cookies. Otra
característica más potente y destacable de PHP es su soporte
para una gran cantidad de bases de datos. (Bakken, Stig Saether;
Aulbach, Alexander; Schmid, Egon; Winstead, Jim; Torben, Lars
Wilson; Lerdorf, Rasmus; Zmievski, Andrei; Ahto, 2002)
Existen tres campos en los que se emplean scripts escritos en
PHP:
• Scripts en la parte del servidor. Este es el campo más
tradicional y el principal campo de trabajo. Se necesitan tres
cosas para que esto funcione. El intérprete PHP (CGI o
módulo), un servidor web y un navegador. Se necesita correr
el servidor web con PHP instalado. El resultado del programa
16
PHP se puede obtener a través del navegador, conectando
con el servidor web.
• Scripts en línea de comandos. Se puede crear un script PHP
y correrlo sin ningún servidor web o navegador. Solamente se
necesita el intérprete PHP para usarlo de esta manera. Este
tipo de uso es ideal para scripts ejecutados regularmente en
Unix o Linux o desde el planificador de tareas en Windows.
Estos scripts también pueden usarse para tareas simples de
procesado de texto.
• Escribir aplicaciones gráficas clientes. PHP no es
probablemente el mejor lenguaje para escribir aplicaciones
gráficas, pero si se quieren utilizar algunas características
avanzadas en programas clientes, se puede utilizar PHP-GTK
para escribirlos. Es también posible escribir aplicaciones
independientes de una plataforma.
PHP también tiene soporte para comunicarse con varios
servicios usando protocolos tales como LDAP, IMAP, SNMP,
NNTP, POP3, HTTP, COM (en Windows) y muchos otros. PHP
soporta WDDX para intercambio de datos entre lenguajes de
programación en web.
1.3.2.7 Symfony
Symfony es una plataforma diseñada para optimizar el desarrollo
de las aplicaciones web basado en el patrón Modelo Vista
Controlador. Permite separar la lógica del negocio, la lógica del
servidor y la presentación de la aplicación web. Proporciona varias
herramientas y clases encaminadas a reducir el tiempo de
desarrollo de una aplicación web compleja, además, automatiza
las tareas más comunes, permitiendo al desarrollador dedicarse
por completo a los aspectos específicos de cada aplicación. El
resultado de todas estas ventajas es que no se debe reinventar la
rueda cada vez que se crea una nueva aplicación web. (Group
and others, 2004).
17
Symfony está desarrollado completamente en PHP 5.3. Ha sido
probado en numerosos proyectos reales y se utiliza en sitios web
de comercio electrónico de primer nivel. Symfony es compatible
con la mayoría de gestores de bases de datos, como MySQL,
PostgreSQL, Oracle y Microsoft SQL Server.
Características (Group and others, 2004):
1. Fácil de instalar y configurar en la mayoría de plataformas
2. Independiente del sistema gestor de bases de datos. Su capa
de abstracción y el uso de ORM permiten cambiar con
facilidad de SGBD en cualquier fase del proyecto.
3. Utiliza programación orientada a objetos y características
como los espacios de nombres
4. Sencillo de usar en la mayoría de casos, aunque es preferible
para el desarrollo de grandes aplicaciones Web que para
pequeños proyectos.
5. Aunque utiliza MVC (Modelo Vista Controlador), tiene su
propia forma de trabajo en este punto, con variantes del MVC
clásico como la capa de abstracción de base de datos, el
controlador frontal y las acciones.
6. Basado en la premisa de “convenir en vez de configurar”, en
la que el desarrollador sólo debe configurar aquello que no es
convencional.
7. Sigue la mayoría de mejores prácticas y patrones de diseño
para la web.
8. Preparado para aplicaciones empresariales y adaptables a
las políticas y arquitecturas propias de cada empresa,
además de ser lo suficientemente estable como para
desarrollar aplicaciones a largo plazo.
9. Código fácil de leer que incluye comentarios de
phpDocumentor y que permite un mantenimiento muy
sencillo.
10. Fácil de extender, lo que permite su integración con las
bibliotecas de otros fabricantes.
11. Una potente línea de comandos que facilitan generación de
código, lo cual contribuye a ahorrar tiempo de trabajo.
18
Ventajas tecnológicas de Symfony:
1. Rápido y consumo menor de memoria.
2. Flexibilidad ilimitada.
3. Ampliable.
4. Estable y sostenible.
5. La alegría de desarrollo.
6. Facilidad de uso.
1.3.2.8. SGBD (Sistema Gestor de Base Datos) MySQL
MySQL es un sistema de administración de bases de datos
relacional (RDBMS). Se trata de un programa capaz de almacenar
una enorme cantidad de datos de gran variedad y de distribuirlos
para cubrir las necesidades de cualquier tipo de organización,
desde pequeños establecimientos comerciales a grandes
empresas y organismos administrativos. MySQL compite con
sistemas RDBMS propietarios conocidos, como Oracle, SQL
Server y DB2. (Mysql, no date)
MySQL incluye todos los elementos necesarios para instalar el
programa, preparar diferentes niveles de acceso de usuario,
administrar el sistema y proteger y hacer volcados de datos.
Puede desarrollar sus propias aplicaciones de base de datos en
la mayor parte de los lenguajes de programación utilizados en la
actualidad y ejecutarlos en casi todos los sistemas operativos,
incluyendo algunos de los que probablemente no ha oído nunca
hablar. MySQL utiliza el lenguaje de consulta estructurado (SQL).
Este lenguaje permite crear bases de datos, así como agregar,
manipular y recuperar datos en función de criterios específicos.
Son muchas las razones para escoger MySQL como solución de
misión crítica para la administración de datos. (Mysql, no date)
• Coste: El coste de MySQL es gratuito para la mayor parte de
los usos y su servicio de asistencia resulta económico.
• Asistencia: MySQL AB ofrece contratos de asistencia a
precios razonables y existe una nutrida y activa comunidad
MySQL.
• Velocidad: MySQL es mucho más rápido que la mayor parte
de sus rivales.
19
• Funcionalidad: MySQL dispone de muchas de las funciones
que exigen los desarrolladores profesionales, como
compatibilidad completa con ACID, compatibilidad para la
mayor parte de SQL ANSI, volcados online, duplicación,
funciones SSL e integración con la mayor parte de los
entornos de programación. Así mismo, se desarrolla y
actualiza de forma mucho más rápida que muchos de sus
rivales, por lo que prácticamente todas las funciones estándar
de MySQL todavía no están en fase de desarrollo.
• Portabilidad: MySQL se ejecuta en la inmensa mayoría de
sistemas operativos y, la mayor parte de los casos, los datos
se pueden transferir de un sistema a otro sin dificultad.
• Facilidad de uso: MySQL resulta fácil de utilizar y de
administrar. Gran parte de las viejas bases de datos presentan
problemas por utilizar sistemas obsoletos, lo que complica
innecesariamente las tareas de administración. Las
herramientas de MySQL son potentes y flexibles, sin sacrificar
su capacidad de uso.
Conexión a una base de datos:
El equipo en el que se ejecuta MySQL y que almacena los datos
se denomina servidor MySQL. Para establecer una conexión a
este servidor, dispone de varias opciones de instalación. En
primer lugar, puede instalar el cliente y el servidor MySQL en su
equipo de escritorio, como ilustra la Ilustración 1.7. En segundo
lugar, puede instalar el cliente MySQL en su equipo de sobremesa
y el servidor MySQL en otro equipo al que se establecerá la
conexión, como se ilustra en la Ilustración 1.8. Por último, su
equipo de sobremesa puede ser cualquier ordenador que se
conecte a otro equipo con un cliente MySQL instalado, que a su
vez se conectara al servidor MySQL, situado en el mismo equipo
o en otro, como muestra la Ilustración 1.9.
20
Ilustración 1.7: Servidor y Cliente MySQL. (Mysql, no date)
Ilustración 1.8: Escritorio y Cliente MySQL junto a un Servidor MySQL. (Mysql,
no date)
Ilustración 1.9: Escritorio, Cliente MySQL y Servidor MySQL. (Mysql, no date)
1.3.2.9. Unified Modeling Language (UML)
El Lenguaje Unificado de Modelado (Unified Modeling Language,
UML) es un lenguaje de modelado visual que se usa para
especificar, construir y documentar artefactos de un sistema.
Captura decisiones y conocimientos sobre los sistemas que se
deben construir. Se usa para entender, diseñar, hojear, configurar,
mantener y controlar la información sobre tales sistemas.
Pretende unificar la experiencia pasada sobre técnicas de
modelado e incorporar las mejores prácticas actuales en un
acercamiento estándar. (James Rumbaugh, Ivar Jaconson, 1999)
21
Ilustración 1.10: UML. (Fernández, 2010)
Características:
• Desplegar los límites de un sistema y sus principales
funciones mediante casos de uso y actores.
• Representar la estructura estáticade un sistema usando
diagramas de clases.
• Modelar los límites de un objetocon diagramas de estados.
• Mostrar la arquitectura de la implementaciónfísica con
diagramas decomponentes y de emplazamiento o
despliegue.
Conceptos y modelos de UML:
• Estructura estática.
• Comportamiento dinámico.
• Construcciones de implementación.
• Organización del modelo.
• Mecanismos de extensión.
22
Ilustración 1.11: Vistas y diagramas de UML. (James Rumbaugh, Ivar
Jaconson, 1999)
1.4. Conclusiones Parciales
En este capítulo se realizó un análisis de los objetivos estratégicos de la
Universidad Central “Marta Abreu” de Las Villas y con ello su misión de hacer más
efectiva la guardia obrera estudiantil. Se realizó un estudio de la metodología y
tecnologías a emplear para dar solución al problema descrito, decidiéndose
utilizar: Bootstrap como plataforma o biblioteca del lado del cliente para el uso de
tecnologías como HTML5, CSS3 y JavaScript; RUP como metodología de
desarrollo de software; UML como lenguaje de modelado; PHP para lenguaje de
programación del lado del servidor, utilizando Symfony3 como plataforma de
desarrollo y MySQL como gestor de base de datos para la herramienta.
23
Capítulo II. Modelación del Negocio y Estimación En el presente capítulo se exponen aspectos relacionados al modelado del negocio, en
el que se describe de forma detallada el proceso de gestión de la planificación y control
de la GOE. Se hace énfasis en sus actores, se precisarán los requisitos tanto
funcionales como no funcionales. Además se presentarán diagramas que
posteriormente ayudarán en la explicación de la implementación del proyecto.
Siempre que se realiza un proyecto de desarrollo de software surge la necesidad de
echar un vistazo al futuro y aceptar un grado de incertidumbre, esto se logra al efectuar
la estimación. Es por esto que dentro de las primeras etapas de un proyecto de software
se formaliza la estimación, dado que afecta a todo el proyecto y en especial a las etapas
de análisis y diseño, en la mayoría de las metodologías de desarrollo de software, dentro
de la fase inicial es donde se formula el proyecto y donde tradicionalmente se realiza la
estimación.
2.1 Modelo del negocio actual
Procedimiento de Planificación: el proceso de la planificación fue descrito en el
epígrafe 1.2.1.
Procedimientos de Control: el proceso de control de la GOE comienza al otro día de
realizada la guardia por el trabajador encargado de esta labor en la facultad, se
verifica que coincida la planificación con los anotados en el Modelo de Control, los
estudiantes que no estén anotados se consideran ausentes a la guardia y tienen
hasta 72 horas para justificar la ausencia, de no ser así son llevados a corte
disciplinaria, las que pueden arrojar diferentes resultados desde la replanificación
de la guardia, hasta la asignación de otras tareas por este órgano, si el estudiante
es reincidente o cometió alguna otra infracción durante el servicio de guardia, las
medidas pueden variar en dependencia a lo establecido en el reglamento
disciplinario de la UCLV y el grado de la transgresión cometida.
2.2 Reglas del negocio a considerar
¿Qué es una regla del negocio?
Las Reglas del Negocio o Conjunto de Reglas de Negocio (Business Rules, por su
descripción en inglés) describen las políticas, normas, operaciones, definiciones y
restricciones presentes en una organización y son de vital importancia para alcanzar
los objetivos misionales. (Becerril, 2015)
24
A continuación, se describe una regla correspondiente al negocio actual:
RN1: Los estudiantes y trabajadores exceptuados por algún motivo bien justificado
no pueden realizar la guardia.
2.3 Actores del negocio
¿Qué es un actor del negocio?
Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o
sistema de información externos; con los que el negocio interactúa. (E.V.A., 2017)
En la siguiente Tabla se observa la descripción de los actores del negocio actual:
Actor del Negocio Descripción
Estudiante Es quien visualiza el listado de las guardias asignadas y ausencias
durante el proceso de planificación y el control de las mismas.
Trabajador Es quien visualiza el listado de las guardias asignadas y ausencias
durante el proceso de planificación y el control de las mismas.
Tabla 2.1: Actores del Negocio.
2.4 Trabajadores del negocio
¿Qué es un trabajador del negocio?
Los trabajadores del negocio representan un rol que juega una persona (o grupo de
personas), una máquina o un sistema automatizado; actuando en el negocio. Son los
que realizan las actividades, interactuando con otros trabajadores del negocio y
manipulando entidades. (E.V.A., 2017)
En la siguiente Tabla se observa el trabajador del negocio actual:
Trabajador del Negocio Descripción
Jefe del Departamento
Administrativo.
Visualiza y controla los listados de estudiantes,
trabajadores y custodios contratados, los planes y las
guardias especiales, se encarga de los procesos
administrativos de apoyo al proceso de la guardia.
Responsable de la
planificación y control de
la GOE.
Es quien atiende directamente la planificación y el control
de la guardia y mantiene dicha información.
Tabla 2.2: Trabajadores del negocio.
25
2.5 Diagrama de casos de uso del negocio
¿Qué es un diagrama de casos de uso del negocio?
Los diagramas de casos de uso del negocio constituyen una representación gráfica de
un conjunto de elementos tales como actores y casos de uso, así como las relaciones y
dependencias que se establecen entre ellos. (E.V.A., 2017)
En la Ilustración 2.1 se observa el diagrama de Casos de Uso que identifica al negocio:
Ilustración 2.1: Diagrama de Casos de Uso del Negocio. (Visual Paradigm for UML 10.1)
2.6 Actores del sistema a automatizar
¿Qué es un actor del sistema?
Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y
que le demanda una funcionalidad. (Gutierrez, 2011)
Actores del sistema Descripción
Vice-Rector que atiende
el proceso de defensa y
seguridad.
Es quien señala del listado global de trabajadores quienes
son los Oficiales de Guardia Superiores (OGS), visualiza
todos los involucrados en las guardias por áreas, visualiza
los custodios contratados, visualiza las planificaciones
especiales de cuadros de dirección y visualiza los planes
especiales por aprobar y gestiona la resolución 176.
Director de Defensa y Seguridad.
Visualiza los OGS, todos los involucrados en las guardias
por áreas, las planificaciones especiales de cuadros de
dirección y gestiona la resolución 176.
Oficial de Guardia
Superior.
Visualiza todas las personas que están de guardia su mismo
día en todas las áreas universitarias.
26
Jefe del Departamento
Administrativo.
Actualiza el listado de estudiantes y trabajadores, registra
los custodios en los períodos especiales, planifica las
guardias en los períodos especiales de los cuadros de
dirección, controla los planes especiales, gestiona las cortes
y consejos disciplinarios, imprime los diferentes tipos de
guardias, gestiona los diferentes tipos de reportes, gestiona
el reglamento de la facultad y gestiona los departamentos
que tiene subordinados y visualiza el listado de estudiantes
y trabajadores por departamento.
Jefe de la Comisión de
Defensa y Seguridad.
Genera los planes especiales, visualiza todas las
planificaciones de su facultad y visualiza los reportes.
Responsable de la
planificación y control
de la GOE.
Es quien atiende directamente el proceso de planificación y
control de la guardia.
Administrador. Gestiona las facultades y direcciones existentes en la UCLV,
además de las fechas de días feriados.
Trabajador. Es quien visualiza el listado de las guardias asignadas
durante el proceso de planificación y el control de las
mismas.
Estudiante. Es quien visualiza el listado de las guardias asignadas
durante el proceso de planificación y el control de las
mismas.
Tabla 2.3: Actores del Sistema.
2.7 Definición de los requisitos funcionales
¿Qué es un requisito funcional?
Son declaraciones de los servicios que proveerá el sistema, de la manera en que este
reaccionará a entradas particulares y de cómo se comportará en situaciones
particulares. Los requisitos funcionales de un sistema describen la funcionalidad o los
servicios que se espera que este provea. (Sommverville, 2005)
A continuación, se muestra la definición de los mismos:
RF1: “Gestionar Listado de Estudiantes”.
El sistema debe listar cada uno de los estudiantes que conforman la matricula docente
y con ello la información referente a cada uno de ellos.
27
RF1.1: Cargar estudiantes.
El sistema debe permitir al usuario cargar el listado de los estudiantes de su facultad.
RF1.2: Adicionar un nuevo estudiante.
El sistema debe permitir al usuario adicionar un nuevo estudiante con los datos que a
este le corresponden.
RF1.3: Modificar datos de un estudiante existente.
El sistema debe brindar la posibilidad de actualizar los datos de un estudiante.
RF1.4: Eliminar un estudiante.
El sistema debe brindar la posibilidad de eliminar un estudiante y con ello todos sus
datos.
RF2: “Gestionar Listado de Trabajadores”.
El sistema debe listar cada uno de los trabajadores que conforman el personal de cada
área universitaria y con ello la información referente a cada uno de ellos.
RF2.1: Cargar trabajadores.
El sistema debe permitir al usuario cargar el listado de los trabajadores de su área.
RF2.2: Adicionar un nuevo trabajador.
El sistema debe permitir al usuario adicionar un nuevo trabajador con los datos que a
este le corresponden.
RF2.3: Modificar datos de un trabajador existente.
El sistema debe brindar la posibilidad de actualizar los datos de un trabajador.
RF4.4: Eliminar un trabajador.
El sistema debe brindar la posibilidad de eliminar un trabajador y con ello todos sus
datos.
RF3: “Gestionar Listado de Custodios Contratados”.
El sistema debe listar cada uno de los custodios contratados y con ello la información
referente a cada uno de ellos.
RF3.1: Adicionar un nuevo custodio.
El sistema debe permitir al usuario adicionar un nuevo custodio con los datos que a este
le corresponden.
RF3.2: Modificar datos de un custodio existente.
El sistema debe brindar la posibilidad de actualizar los datos de un custodio.
RF3.3: Eliminar un custodio.
El sistema debe brindar la posibilidad de eliminar un custodio y con ello todos sus datos.
RF4: “Gestionar Planificaciones”.
El sistema debe brindar la posibilidad de listar todas las planificaciones de estudiantes
y trabajadores, así como la posibilidad de realizar acciones sobre ellas.
28
RF4.1: Generar planificación.
El sistema debe permitir al usuario realizar las planificaciones de forma automatizada.
RF4.2: Adicionar una nueva planificación.
El sistema debe permitir al usuario adicionar una nueva planificación con los datos que
a este le corresponden.
RF4.3: Modificar una planificación existente.
El sistema debe brindar la posibilidad de actualizar una planificación y sus datos.
RF4.4: Eliminar una planificación.
El sistema debe brindar la posibilidad de eliminar una planificación y con ello todos sus
datos.
RF5: “Gestionar Ausencias”.
El sistema debe brindar la posibilidad de listar todas las ausencias de estudiantes y
trabajadores, así como la posibilidad de realizar acciones sobre ellas.
RF5.1: Adicionar una nueva ausencia.
El sistema debe permitir al usuario insertar una nueva ausencia con los datos que a este
le corresponden.
RF5.2: Modificar una ausencia existente.
El sistema debe brindar la posibilidad de actualizar una ausencia y sus datos.
RF5.3: Eliminar una ausencia.
El sistema debe brindar la posibilidad de eliminar una ausencia y con ello todos sus
datos.
RF6: “Gestionar Excepciones”.
El sistema debe brindar la posibilidad de listar todas las excepciones de estudiantes y
trabajadores y pueda realizar las acciones correspondientes.
RF6.1: Adicionar una excepción.
El sistema debe permitir al usuario insertar una nueva persona exceptuada con los datos
correspondientes.
RF6.2: Modificar una excepción.
El sistema debe brindar la posibilidad de actualizar los datos de una persona exceptuada
existente.
RF6.3: Eliminar una excepción.
El sistema debe brindar la posibilidad de eliminar una persona exceptuada existente y
sus datos.
RF7: “Gestionar Bajas”.
El sistema debe permitir al usuario listar todas las bajas de estudiantes y trabajadores
que han ocurrido hasta el momento.
29
RF7.1: Adicionar una baja.
El sistema debe permitir al usuario adicionar una baja y con ello los datos
correspondientes.
RF7.2: Modificar una baja.
El sistema debe brindar la posibilidad de actualizar los datos de una baja y con ello cada
uno de los datos que conforman la baja.
RF7.3: Eliminar una baja.
El sistema debe brindar la posibilidad de eliminar una baja existente y sus datos.
RF8: “Gestionar Consejos”.
El sistema debe permitir al usuario listar todos los consejos que se han realizado hasta
el momento con la información que los conforma a cada uno de estos.
RF8.1: Adicionar un consejo.
El sistema debe permitir al usuario adicionar un consejo a un estudiante con los datos
correspondientes del mismo.
RF8.2: Modificar un consejo.
El sistema debe brindar la posibilidad de actualizar los datos de un consejo realizado a
un estudiante y con ello cada uno de los datos que lo conforman.
RF8.3: Eliminar un consejo.
El sistema debe brindar la posibilidad de eliminar un consejo de un estudiante existente
y sus datos.
RF9: “Gestionar Cortes”.
El sistema debe permitir al usuario listar todas las cortes que se han realizado hasta el
momento con la información que los conforma a cada uno de estos.
RF9.1: Adicionar una corte.
El sistema debe permitir al usuario adicionar una corte a un estudiante con los datos
correspondientes del mismo.
RF9.2: Modificar una corte.
El sistema debe brindar la posibilidad de actualizar los datos de una corte realizada a
un estudiante y con ello cada uno de los datos que lo conforman.
RF9.3: Eliminar una corte.
El sistema debe brindar la posibilidad de eliminar una corte de un estudiante existente y
sus datos.
RF10: “Gestionar Responsables de los Consejos”.
El sistema debe permitir al usuario listar todos los responsables de los consejos con la
información que los conforma a cada uno de estos.
30
RF10.1: Adicionar un responsable de consejo.
El sistema debe permitir al usuario insertar un responsable con los datos
correspondientes del mismo.
RF10.2: Eliminar un responsable de consejo.
El sistema debe brindar la posibilidad de eliminar un responsable existente y sus datos.
RF11: “Gestionar Responsables de las Cortes”.
El sistema debe permitir al usuario listar todos los responsables de las cortes con la
información que los conforma a cada uno de estos.
RF11.1: Adicionar un responsable de corte.
El sistema debe permitir al usuario insertar un responsable con los datos
correspondientes del mismo.
RF11.2: Eliminar un responsable de corte.
El sistema debe brindar la posibilidad de eliminar un responsable existente y sus datos.
RF12: “Gestionar Reportes”.
El sistema debe brindar la posibilidad de listar todos los reportes realizados hasta el
momento y con ello la información perteneciente a cada uno de ellos.
RF12.1: Crear reporte.
El sistema debe permitir al usuario crear un reporte con los datos correspondientes del
mismo.
RF12.2: Generar reporte.
El sitio debe brindar la posibilidad de generar un reporte con la información pertinente
que debe conformar el mismo.
RF13: “Gestionar Planes Especiales”.
El sitio debe mostrar un listado con todos los planes especiales creados hasta el
momento.
RF13.1: Adicionar un plan especial.
El sistema debe permitir al usuario adicionar un plan especial con los datos
correspondientes del mismo.
RF13.2: Eliminar un plan especial.
El sistema debe brindar la posibilidad de eliminar un responsable existente y sus datos.
RF13.3: Generar los planes especiales.
El sitio debe brindar la posibilidad de generar un plan especial con la información
pertinente que debe conformar al mismo.
RF13.4: Aprobarlos planes especiales.
El sitio debe brindar la posibilidad de aprobar un plan especial.
31
RF14: “Imprimir GOE”.
El sitio debe de ser capaz de generar todos los documentos de los diferentes tipos de
guardias para su impresión.
RF15: “Gestionar Resolución No. 176”.
El sitio debe de ser capaz de subir la Resolución No. 176 para que todos tengan acceso
a ella para descargarla.
RF15.1: Listar la resolución subida.
El sistema debe permitir al usuario listar la resolución subida al sitio con los datos
correspondientes del mismo.
RF15.2: Subir la resolución.
El sistema debe brindar la posibilidad de subir una resolución al sitio y sus datos.
RF15.3: Eliminar la resolución.
El sistema debe brindar la posibilidad de eliminar la resolución existente.
RF16: “Gestionar el Reglamento de Cada Facultad”.
El sitio debe de ser capaz de subir el reglamento de cada facultad para que todos tengan
acceso a ella para descargarla.
RF16.1: Listar los reglamentos subidos.
El sistema debe permitir al usuario listar los reglamentos subidos al sitio con los datos
correspondientes del mismo.
RF16.2: Subir el reglamento.
El sistema debe brindar la posibilidad de subir un reglamento al sitio y sus datos.
RF16.3: Eliminar un reglamento.
El sistema debe brindar la posibilidad de eliminar un reglamento existente.
RF17: “Gestionar Departamentos”.
El sistema debe permitir al usuario listar todos los departamentos que tiene su facultad.
RF17.1: Listar estudiantes y trabajadores por departamento.
El sistema debe permitir al usuario adicionar una corte a un estudiante con los datos
correspondientes del mismo.
RF17.2: Adicionar un departamento.
El sistema debe permitir al usuario adicionar un departamento con los datos
correspondientes del mismo.
RF17.3: Modificar un departamento.
El sistema debe brindar la posibilidad de actualizar los datos de un departamento y con
ello cada uno de los datos que lo conforman.
RF17.4: Eliminar un departamento.
El sistema debe brindar la posibilidad de eliminar un departamento existente y sus datos.
32
RF18: “Gestionar Causas”.
El sistema debe permitir al usuario listar todas las causas posibles de las ausencias.
RF18.1: Adicionar una causa.
El sistema debe permitir al usuario adicionar una causa.
RF18.2: Modificar una causa.
El sistema debe brindar la posibilidad de actualizar una causa.
RF18.3: Eliminar una causa.
El sistema debe brindar la posibilidad de eliminar una causa existente.
RF19: “Visualizar GOE-UCLV”.
El sistema debe permitir al usuario listar las diferentes guardias, los custodios y las
planificaciones especiales de cuadro de dirección por áreas universitarias.
RF20: “Gestionar Facultades”.
El sistema debe permitir al usuario listar las facultades existentes y sus datos.
RF20.1: Adicionar una facultad.
El sistema debe permitir al usuario adicionar una facultad con los datos
correspondientes del mismo.
RF20.2: Modificar una facultad.
El sistema debe brindar la posibilidad de actualizar los datos de una facultad y con ello
cada uno de los datos que lo conforman.
RF20.3: Eliminar una facultad.
El sistema debe brindar la posibilidad de eliminar una facultad existente y sus datos.
RF21: “Gestionar Direcciones”.
El sistema debe permitir al usuario listar las direcciones existentes y sus datos.
RF21.1: Adicionar una dirección.
El sistema debe permitir al usuario adicionar una dirección con los datos
correspondientes del mismo.
RF21.2: Modificar una dirección.
El sistema debe brindar la posibilidad de actualizar los datos de una dirección y con ello
cada uno de los datos que lo conforman.
RF21.3: Eliminar una dirección.
El sistema debe brindar la posibilidad de eliminar una dirección existente y sus datos.
RF22: “Gestionar Días Feriados”.
El sistema debe permitir al usuario listar fechas que son feriados.
RF22.1: Adicionar un día feriado.
El sistema debe permitir al usuario adicionar una dirección con los datos
correspondientes del mismo.
33
RF22.2: Eliminar un día feriado.
El sistema debe brindar la posibilidad de eliminar un día feriado.
RF22.3: Eliminar todos los días feriados.
El sistema debe brindar la posibilidad de eliminar todos los días feriados.
RF23: “Visualizar Listado de Planificaciones y Ausencias”.
El sistema debe permitir al usuario visualizar el listado de las guardias asignadas y
ausencias durante el proceso de planificación y el control de las mismas.
RF24: “Señalar OGS”.
El sistema debe permitir al Vice-Rector señalar listado global de trabajadores quienes
son los Oficiales de Guardia Superiores (OGS).
RF25: “Visualizar Planificaciones Especiales De Cuadros de Dirección”.
El sistema debe permitir al usuario visualizar las planificaciones especiales de cuadro
de dirección.
2.8 Definición de los requisitos no funcionales
¿Qué es un requisito no funcional?
Los requisitos no funcionales especifican propiedades del sistema, como pueden ser la
seguridad y la fiabilidad del mismo. Estos requisitos no solo hacen referencia al sistema
que se va a desarrollar, también consideran algunas restricciones, es decir, se encargan
de definir aspectos como, por ejemplo, que estándares de calidad se deben seguir en
el desarrollo del sistema. (Martínez and Silva, 2010)
A continuación, se muestra la definición de los mismos:
“Requisitos de Software”:
RNF1: El sistema utilizara como gestor de base de datos MySQL.
RNF2: Para poder utilizar el sistema se debe tener instalado un servidor AMPPS o
cualquier otro servidor WEB.
RNF3: En las PC clientes se debe tener instalado un Navegador Web: Mozilla Firefox,
Ópera o Internet Explorer.
“Usabilidad”:
RNF4: El sistema será de fácil acceso y uso para cualquier usuario que acceda a él,
requiriéndose un mínimo proceso de aprendizaje y conocimientos básicos de
computación y trabajo en la Web.
“Rendimiento”:
RNF5: El sistema deberá ser capaz de gestionar toda la información de los contenidos
que se suban o descarguen del sitio por todos los usuarios que accedan a esta y las
demás funcionalidades.
34
RNF6: La interacción con la Base de Datos y la carga de las páginas dinámicas debe
ser lo más rápida posible para dar respuesta a las solicitudes de los usuarios.
RNF7: Debe estar disponible las 24 horas del día.
RNF8: Soportará a un amplio número de usuarios conectados simultáneamente en
cualquier momento dado, pues el sitio estará publicado en la Intranet.
“Soporte”:
RNF9: Fácil para el mantenimiento, de configuración sencilla y factible para los clientes.
“Requisitos de portabilidad”:
RNF10: El producto no requiere de instalación puesto que está desarrollado sobre una
plataforma web.
RNF11: El sistema debe poder ejecutarse en cualquier sistema operativo Windows 95
o superior, al igual que en servidores de Debian.
“Requisitos de interfaz”:
RNF12: La aplicación será diseñada con una interfaz sencilla, fácil de usar, de manera
que agilice y facilite el trabajo con el software.
RNF13: Los colores y la estructura de los componentes estarán distribuidos para lograr
que el usuario se sienta a gusto y tranquilo durante la navegación.
“Seguridad”
RNF14: La seguridad del sitio se garantizará a través de la implementación de un
sistema de roles de usuario, donde cada uno de ellos tendrá una función definida y
acceso a ejecutar sólo las acciones que le correspondan.
RNF15: La base de datos estará protegida contra intrusiones externas y el contenido
del sitio sólo podrá ser modificado por los administradores.
“Ayuda y documentación”:
RNF16: La aplicación debe proporcionar la ayuda al usuario para comprender fácilmente
su modo de uso.
2.9 Casos de Uso del Sistema
¿Qué es un caso de uso del sistema?
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse
para llevar a cabo algún proceso. Los personajes o entidades que participarán en un
caso de uso se denominan actores. (Sommverville, 2005)
Los casos de Uso del sistema son:
CU1: Gestionar Estudiantes.
CU2: Gestionar Trabajadores.
CU3: Gestionar Custodios Contratados.
35
CU4: Gestionar Planificaciones.
CU5: Gestionar Ausencias.
CU6: Gestionar Excepciones.
CU7: Gestionar Bajas.
CU8: Gestionar Consejos.
CU9: Gestionar Cortes.
CU10: Gestionar Responsables de Consejos.
CU11: Gestionar Responsables de Cortes.
CU12: Gestionar Reporte.
CU13: Gestionar Planes Especiales.
CU14: Imprimir GOE.
CU15: Gestionar Resolución No. 176.
CU16: Gestionar Reglamento.
CU17: Gestionar Departamentos.
CU18: Gestionar Causas.
CU19: Visualizar GOE-UCLV.
CU20: Gestionar Facultades.
CU21: Gestionar Direcciones.
CU22: Gestionar Días Feriados.
CU23: Visualizar Listado de Planificaciones y Ausencias.
CU24: Señalar OGS.
CU25: Visualizar Planificaciones Especiales De Cuadros de Dirección.
En las ilustraciones 2.2, 2.3, 2.4, 2.5, 2.6 y 2.7 se muestra el diagrama de Casos de Uso
del sistema para los diferentes actores del sistema:
Ilustración 2.2: Diagrama de Casos de Uso del Sistema Actor Jefe Departamento
Administrativo. (Visual Paradigm for UML 10.1)
36
Ilustración 2.3: Diagrama de Casos de Uso del Sistema Actor Responsable de la planificación y
control. (Visual Paradigm for UML 10.1)
Ilustración 2.4: Diagrama de Casos de Uso del Sistema Actor Jefe de Comisión. (Visual
Paradigm for UML 10.1)
37
Ilustración 2.5: Diagrama de Casos de Uso del Sistema Actores UCLV. (Visual Paradigm for
UML 10.1)
Ilustración 2.6: Diagrama de Casos de Uso del Sistema Actor Administrador. (Visual Paradigm
for UML 10.1)
Ilustración 2.7: Diagrama de Casos de Uso del Sistema Actores Estudiante-Trabajador. (Visual
Paradigm for UML 10.1)
38
2.10 Casos de uso del Sistema (Significativos)
¿Qué es un caso de uso significativo?
Los casos de uso significativos son aquellos que nos ayudan a mitigar los riesgos más
importantes, aquellos que son los más importantes para los usuarios del sistema, y
aquellos que nos ayudan a cubrir todas las funcionalidades significativas, de forma que
nada quede en penumbra.
En este sistema los Casos de Uso significativos son los siguientes:
• Gestionar Planificación: sobre este caso de uso de uso descansa todo lo
referente a la gestión de la planificación de la guardia, dando la posibilidad al
usuario de controlar toda la información de estos, sabiendo que día le toca,
generar las guardias de forma automatizada, poder insertar una nueva
planificación con todos los datos correspondientes, modificar cualquiera de ello,
así como eliminar una por cualquier motivo.
• Gestionar Ausencia: este caso de uso nos permite gestionar toda la información
relacionada con las ausencias, modificar el motivo de la ausencia y eliminar la
ausencia en caso de una posible equivocación.
2.11 Descripción de los casos de uso del Sistema
Caso de uso del sistema Gestionar Planificación
Actor Responsable de la planificación y control de la GOE.
Propósito Gestionar toda la información referente a la gestión y
control de las planificaciones.
Resumen Inicia cuando el Responsable de la planificación y
control de la GOE selecciona la opción
“Planificación”, seguidamente puede insertar,
actualizar o eliminar una planificación y finaliza
cuando el Responsable de la planificación y control
de la GOE termina de ejecutar una de estas tres
operaciones.
Responsabilidades Gestionar la información relacionada con las
planificaciones de los estudiantes y trabajadores.
Casos de uso asociados
Precondiciones Conexión a la base de datos
39
Prototipos de interfaz
Flujo normal de eventos. Sección A: Generar Planificación
Acción del actor Respuesta del sistema
1. El Responsable de la planificación y
control de la GOE selecciona la opción
de “Planificación”.
3. El Responsable de la planificación y
control de la GOE selecciona la opción
generar.
5. El Responsable de la planificación y
control de la GOE escoge la forma de
planificación que necesite.
2. El sistema muestra una tabla con los datos
referentes a cada una de las planificaciones de los
estudiantes o trabajadores.
4. El sistema muestra una interfaz con las formas de
planificar la guardia.
6. El sistema realiza la planificación e inserta los
datos en la base de datos.
7. Muestra un mensaje de éxito.
40
Flujo normal de eventos. Sección B: Nueva Planificación
Acción del actor Respuesta del sistema
1. El Responsable de la planificación y
control de la GOE selecciona la opción
de “Planificación”.
3. El Responsable de la planificación y
control de la GOE selecciona la opción
insertar.
5. El Responsable de la planificación y
control de la GOE llena los campos y
acepta.
2. El sistema muestra una tabla con los datos
referentes a cada una de las planificaciones de los
estudiantes o trabajadores.
4. El sistema muestra un formulario con los datos
necesarios para insertar una planificación.
6. El sistema introduce los datos en la base de datos.
7. Muestra un mensaje de éxito.
Flujos alternativos 1
5. El Responsable de la planificación y
control de la GOE llena los campos y
acepta.
7. El Responsable de la planificación y
control de la GOE verifica todos los
campos y acepta.
6. El sistema muestra un mensaje de error donde
indica que existen campos vacíos.
Flujos alternativos 2
5. El Responsable de la planificación y
control de la GOE llena los campos y
acepta.
6. El sistema muestra un mensaje de error donde
indica que algún campo contiene caracteres
incorrectos.
41
7. El Responsable de la planificación y
control de la GOE verifica todos los
campos y acepta.
Flujo normal de los eventos. Sección C: Actualizar Planificación
Acción del actor Respuesta del sistema
1. El Responsable de la planificación y
control de la GOE selecciona una
planificación correspondiente a un
estudiante o un trabajador.
2. El Responsable de la planificación y
control de la GOE hace click en el ícono
“Editar”
4. El Responsable de la planificación y
control de la GOE edita los campos de
la planificación que desee y acepta.
3. El sistema carga la planificación correspondiente y
muestra sus datos en un formulario.
5. El sistema actualiza los datos de la planificación en
la base de datos.
6. Muestra mensaje de éxito.
Flujos alternativos 1
4. El Responsable de la planificación y
control de la GOE edita los campos de
la planificación que desee y acepta.
6. El Responsable de la planificación y
control de la GOE verifica que los
campos estén llenos y acepta.
5. El sistema muestra un mensaje de error donde
indica que algún campo ha quedado vacío.
Flujos alternativos 2
4. El Responsable de la planificación y
control de la GOE edita los campos de
la planificación que desee y acepta.
5. El sistema muestra un mensaje de error donde
indica que algún campo contiene caracteres
incorrectos.
42
6. El Responsable de la planificación y
control de la GOE verifica que los
campos estén correctos y acepta.
Flujo normal de los eventos. Sección D: Eliminar Planificación
Acción del actor Respuesta del sistema
1. El Responsable de la planificación y
control de la GOE selecciona una
planificación correspondiente a un
estudiante o un trabajador.
2. El Responsable de la planificación y
control de la GOE hace click en el ícono
“Eliminar”.
4. El Responsable de la planificación y
control de la GOE hace click en el botón
aceptar.
3. El sistema muestra un cartel de confirmación.
5. El sistema elimina la planificación en la base de
datos.
6. Muestra mensaje de éxito.
Post condiciones La base de datos debe quedar actualizada de
acuerdo a las operaciones realizadas en las
secciones A, B, C y D.
Tabla 2.4: Descripción del caso de uso Planificación.
43
Caso de uso del sistema Gestionar Ausencia
Actor Responsable de la planificación y control de la GOE.
Propósito Gestionar toda la información referente a la gestión y
control de las ausencias.
Resumen Inicia cuando el Responsable de la planificación y
control de la GOE selecciona la opción “Ausencias”,
seguidamente pude insertar, actualizar o eliminar una
ausencia de un estudiante o un trabajador y finaliza
cuando el Responsable de la planificación y control
de la GOE termina de ejecutar una de estas tres
operaciones.
Responsabilidades Gestionar la información relacionada con el control
de las ausencias de los estudiantes y trabajadores.
Casos de uso asociados
Precondiciones Conexión a la base de datos
Prototipos de interfaz
Flujo normal de eventos. Sección A: Nueva Ausencia
Acción del actor Respuesta del sistema
1. El Responsable de la planificación y
control de la GOE selecciona la opción
de “Ausencias”.
44
3. El Responsable de la planificación y
control de la GOE selecciona la opción
insertar.
5. El Responsable de la planificación y
control de la GOE llena los campos y
acepta.
2. El sistema muestra una tabla con los datos
referentes a cada una de las ausencias de los
estudiantes o trabajadores.
4. El sistema muestra un formulario con los datos
necesarios para insertar una ausencia.
6. El sistema introduce los datos en la base de datos.
7. Muestra un mensaje de éxito.
Flujos alternativos 1
5. El Responsable de la planificación y
control de la GOE llena los campos y
acepta.
7. El Responsable de la planificación y
control de la GOE verifica todos los
campos y acepta.
6. El sistema muestra un mensaje de error donde
indica que existen campos vacíos.
Flujos alternativos 2
5. El Responsable de la planificación y
control de la GOE llena los campos y
acepta.
7. El Responsable de la planificación y
control de la GOE verifica todos los
campos y acepta.
6. El sistema muestra un mensaje de error donde
indica que algún campo contiene caracteres
incorrectos.
Flujo normal de los eventos. Sección B: Actualizar Ausencia
Acción del actor Respuesta del sistema
45
1. El Responsable de la planificación y
control de la GOE selecciona un recurso
de los existentes hasta el momento.
2. El Responsable de la planificación y
control de la GOE hace click en el ícono
“Editar”.
4. El Responsable de la planificación y
control de la GOE edita los campos de
la ausencia que desee y acepta.
3. El sistema carga la ausencia correspondiente y
muestra sus datos en un formulario.
5. El sistema actualiza los datos de la ausencia en la
base de datos.
6. Muestra mensaje de éxito.
Flujos alternativos 1
4. El Responsable de la planificación y
control de la GOE edita los campos de
la ausencia que desee y acepta.
6. El Responsable de la planificación y
control de la GOE verifica que los
campos estén llenos y acepta.
5. El sistema muestra un mensaje de error donde
indica que algún campo ha quedado vacío.
Flujos alternativos 2
4. El Responsable de la planificación y
control de la GOE edita los campos de
la ausencia que desee y acepta.
6. El Responsable de la planificación y
control de la GOE verifica que los
campos estén correctos y acepta.
5. El sistema muestra un mensaje de error donde
indica que algún campo contiene caracteres
incorrectos.
46
Flujo normal de los eventos. Sección C: Eliminar Ausencia
Acción del actor Respuesta del sistema
1. El Responsable de la planificación y
control de la GOE selecciona una
ausencia correspondiente a un
estudiante o un trabajador.
2. El Responsable de la planificación y
control de la GOE hace click en el ícono
“Eliminar”.
4. El Responsable de la planificación y
control de la GOE hace click en el botón
aceptar.
3. El sistema muestra un cartel de confirmación.
5. El sistema elimina los datos de la ausencia en la
base de datos.
6. Muestra mensaje de éxito.
Post condiciones La base de datos debe quedar actualizada de
acuerdo a las operaciones realizadas en las
secciones A, B y C.
Tabla 2.5: Descripción del caso de uso Ausencias.
2.12 Planificación basada en uno de los métodos de estimación
Al principio, el coste del software constituía un porcentaje del coste total de los
sistemas basados en computadora. Un error considerable en las estimaciones del
coste del software tenía relativamente poco impacto. Hoy en día, el software es el
elemento más caro de la mayoría de los sistemas informáticos. Un gran error en la
estimación del coste puede ser lo que marque la diferencia entre beneficios y
pérdidas. (Pressman and Ph, 1997).
2.12.1 Cálculo de puntos de casos de uso sin ajustar.
Ecuación:
UUCP = UAW + UUCW
= 27 + 145
= 172
47
Donde:
UUCP: Puntos de Casos de Uso sin ajustar.
UAW: Factor de Peso de los Actores sin ajustar.
UUCW: Factor de Peso de los Casos de Uso sin ajustar.
Factor de Peso de los Actores sin ajustar (UAW).
Tipo de
actor
Descripción Factor de
peso
Número de
actores
Simple Otro sistema que interactúa con el
sistema a desarrollar mediante
una interfaz de programación
(API, Application Programming
Interface).
1 0
Medio Otro sistema que interactúa con el
sistema a desarrollar mediante un
protocolo o una interfaz basada en
texto.
2 0
Complejo Una persona que interactúa con el
sistema mediante una interfaz
gráfica.
3 9
Tabla 2.6: Factor de Peso de los Actores sin ajustar.
Entonces:
UAW= Σ (Actor i * Factor de Peso i)
= (0 * 1) + (0 * 2) + (3 * 9)
= 27
Factor de Peso de los Casos de Uso sin ajustar (UUCW).
Tipo de caso
de uso
Descripción Factor de
peso
Número de
casos de uso
Simple El Caso de Uso contiene de 1
a 3 transacciones.
5 21
Medio El Caso de Uso contiene de 4
a 7 transacciones.
10 4
Complejo El Caso de Uso contiene más
de 8 transacciones.
15 0
Tabla 2.7: Factor de Peso de los Casos de Uso sin ajustar.
48
Entonces:
UUCW = Σ (Caso de Uso i* Factor de Peso i)
= (21 * 5) + (4 * 10) + (0 * 15)
= 105 + 40 = 145
2.12.2 Cálculo de puntos de Casos de Uso ajustados.
Para el cálculo de los Casos de Uso ajustado se utilizan las siglas UCP y se
obtiene al multiplicar el UUCP el TCF y el EF quedando de la siguiente forma:
UCP = UUCP * TCF * EF
UCP = 172 * 1.08 * 0.8 = 148.608
Donde:
UCP: Puntos de Casos de Uso ajustado.
UUCP: Puntos de Casos de Uso sin ajustar.
TCF: Factor de complejidad técnica.
EF: Factor de Ambiente.
2.12.2.1 Factor de complejidad técnica (TCF)
Este coeficiente se calcula mediante la cuantificación de un conjunto de
13 factores que determinan la complejidad de los módulos del sistema.
Cada uno de los factores se cuantifica con un valor de 0 a 5, donde 0
significa un aporte irrelevante y 5 un aporte muy importante.
Número de factor Descripción Peso Valor Factor
T1 Sistema Distribuido. 2 3 6
T2 Tiempo de respuesta. 1 5 5
T3 Eficiencia por el usuario. 1 5 5
T4 Proceso interno complejo. 1 4 4
T5 Reusabilidad. 1 4 4
T6 Facilidad de instalación. 0.5 5 2.5
T7 Facilidad de uso 0.5 5 2.5
T8 Portabilidad 2 4 8
T9 Facilidad de cambio. 1 4 4
T10 Concurrencia 1 3 3
T11 Objetivos especiales de
seguridad.
1 3 3
T12 Acceso directo a terceras
partes.
1 1 1
49
T13 Facilidades especiales de
entrenamiento a usuarios
finales.
1 0 0
Total Factor
48
Tabla 2.8: Factor de complejidad técnica.
El cálculo del factor de complejidad técnica se realiza mediante la
siguiente ecuación:
TCF = 0.6 + 0.01 * Σ (Pesoix Valor asignadoi)
TCF = 0.6 + 0.01 * 48
TCF = 1.08
2.12.2.2 Factor de ambiente (EF).
Los factores sobre los cuales se realiza la evaluación son 8 puntos, los
que están relacionados con los conocimientos y habilidades del grupo de
persona que se encuentran en el proyecto, lo que produce un gran
impacto en las estimaciones de tiempo.
Número del
factor
Descripción Peso Valor Factor
E1 Familiaridad con el modelo del
proyecto usado.
1.5 4 6
E2 Experiencia en la aplicación 0.5 4 2
E3 Experiencia en orientación a
objetos.
1 4 4
E4 Capacidad del analista líder. 0.5 0 0
E5 Motivación. 1 5 5
E6 Estabilidad de los
requerimientos.
2 3 6
E7 Personal media jornada. -1 0 0
E8 Dificultad en lenguaje de
programación.
-1 3 -3
Total 20
Tabla 2.9: Factor de ambiente.
50
El cálculo del factor de ambiente se realiza mediante la siguiente
ecuación:
EF = 1.4 – 0.03 * Σ (Pesoix Valor asignadoi)
EF = 1.4 – 0.03 * 20
EF = 0.8
2.12.3 Esfuerzo horas-hombre (E)
Este cálculo se realiza con el fin de tener una aproximación del esfuerzo,
pensando solo en el desarrollo según las funcionalidades de los Casos de Uso.
Para el cálculo del mismo se utiliza la siguiente ecuación:
E = UCP * CF
E = 148.608 * 20 = 2972.16
Donde:
E: Esfuerzo estimado en horas-hombre
UCP: Puntos de Casos de Uso ajustados
CF: Factor de conversión (20 horas-hombre por defecto)
2.12.4 Estimación del esfuerzo del proyecto
En la siguiente tabla se destaca la distribución en porcentaje del esfuerzo
total de desarrollo del proyecto:
Actividad Porcentaje
Análisis 10.00%
Diseño 10.00%
Programación 60.00%
Pruebas 10.00%
Sobrecarga (otras actividades) 10.00%
Tabla 2.10: Distribución genérica del esfuerzo.
Con la distribución antes mostrada y tomando como entrada la estimación de
tiempo calculada a partir de los puntos de casos de uso, se pueden calcular las
demás estimaciones para obtener la duración total del proyecto.
Actividad Porcentaje Horas / hombre
Análisis 10.00% 594.43
Diseño 10.00% 594.43
Programación 60.00% 3566.59
Pruebas 10.00% 594.43
Sobrecarga (otras actividades) 10.00% 594.43
Total 100.00% 5944.32
Tabla 2.11: Esfuerzo Calculado.
51
2.12.5 Cálculo del esfuerzo total
Etotal = Σ actividades
Etotal = 5944.32 horas/hombres
Donde:
ETotal: esfuerzo total
2.12.6 Cálculo del tiempo de desarrollo
TDesarrollo = ETotal / CHTotal / CHTrabajo
TDesarrollo = 5944.32 / 1 / 8
TDesarrollo = 743.04
Donde:
TDesarrollo: tiempo de desarrollo total en horas.
CHTotal: cantidad total de hombres.
CHTrabajo: cantidad de horas de trabajo diario.
2.12.7 Cálculo del costo
CostoTotal = ETotal * CHTotal * TH
CostoTotal = 5944.32 * 1 * 3.75
CostoTotal = $22291.20
Donde:
TH: El salario promedio de 1 desarrollador es de $600 y por tanto la
TH = 600 / 160 = 3.75
2.13 Conclusiones Parciales
La descripción del negocio presentada mostró cómo se realizaba el proceso de gestión
de la planificación y el control de la GOE. Se identificó como trabajador del negocio al
Responsable de la planificación y control de la GOE quien interactúa de forma directa
en el proceso de análisis y se impone como actor principal del sistema. Del proceso
antes mencionado se descubrieron los requisitos funcionales y no funcionales, que
guiaron a través de los casos de usos del sistema el desarrollo de la solución que se
propuso.
Una vez realizada la estimación del proyecto mediante el método de esfuerzo de caso
de uso se estimó que en un período de 743 días trabajando 8 horas diarias el costo total
sería de $22291.20. Con el análisis realizado en este capítulo quedan plasmadas las
bases para que se cree una propuesta computacional.
52
Capítulo III. Descripción de la propuesta de solución En el presente capítulo se realiza un análisis de la herramienta realizada como
propuesta de solución, partiendo de la arquitectura de software utilizada y la
especificación de diferentes diagramas como son los diagramas de secuencia, diagrama
de clases, diagrama de despliegue y los modelos conceptuales y físicos de la base de
datos.
3.1 Arquitectura del Sistema
La arquitectura utilizada para la implementación de la aplicación es Modelo Vista
Controlador (MVC). MVC es un patrón de arquitectura del software que separa la lógica
de negocio de la interfaz de usuario, facilita la evolución por separado de ambos
aspectos e incrementa reutilización y flexibilidad. (Mvc, 2008)
• Modelo: Es la capa donde se trabaja con los datos, por tanto, contendrá
mecanismos para acceder a la información y también para actualizar su estado.
• Vista: Es lo que utilizan los usuarios para interactuar con la aplicación. Esta
presenta el modelo en un formato adecuado para interactuar, usualmente la
interfaz de usuario. La vista es responsable de dar el estado al modelo.
• Controlador: Contiene el código necesario para responder a las acciones que se
solicitan en la aplicación, como visualizar un elemento, realizar una búsqueda de
información, etc. En realidad, es una capa que sirve de enlace entre las vistas y
los modelos, respondiendo a los mecanismos que puedan requerirse para
implementar las necesidades de la aplicación. (Alvarez, 2014)
A continuación, en la ilustración 3.1, se muestra la arquitectura del sistema:
Ilustración 3.1: El patrón Modelo Vista Controlador. (Alvarez, 2014)
53
Symfony está basado en este patrón clásico del diseño web.
Cuando el usuario solicita ver la portada del sitio, internamente sucede lo siguiente:
1. El sistema de enrutamiento determina qué Controlador está asociado con la página
de la portada.
2. Symfony ejecuta el Controlador asociado a la portada.
3. El Controlador solicita al Modelo los datos necesarios.
4. Con los datos devueltos por el Modelo, el Controlador solicita a la Vista que cree
una página mediante una plantilla y que inserte los datos del Modelo.
5. El Controlador entrega al servidor la página creada por la Vista.
3.2 Diagrama de clases de diseño
¿Qué es un diagrama de clases de diseño?
Un Diagrama de Clases de Diseño muestra la especificación para las clases de una
aplicación, incluye la siguiente información:
• Clases, asociaciones y atributos.
• Interfaces, con sus operaciones y constantes.
• Métodos.
• Navegabilidad.
• Dependencias.
A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra
definiciones de entidades más que conceptos del mundo real. En laIlustración 3.2 se
muestra un ejemplo de Diagrama de Clases de Diseño sencillo que corresponde al caso
de uso del diseño Planificación (adicionar), el cual parte de una petición del usuario de
la vista delas planificaciones que tienen estudiantes y trabajadores (Listado de
Planificaciones), el controlador PlanificacionController es el encargado de construir la
misma, comprobando los requisitos de seguridad que permitirán al usuario acceder a
esta información, de ser posible muestra los datos de cada planificación y si el usuario
desea insertar una nueva planificación a un estudiante o trabajador, la vista Listado de
Planificaciones contendrá un formulario para este propósito. Los nuevos datos son
validados y el controlador actualiza el modelo dela nueva planificación, por último, el
controlador genera la vista para el Listado de Planificaciones con los datos
anteriormente registrados.
54
Ilustración 3.2: Diagrama de clase de Planificación. (Visual Paradigm for UML 10.1)
La Ilustración 3.3 corresponde al caso de uso del diseño Gestionar Ausencias
(adicionar), de igual manera que en el caso de uso descrito anteriormente, parte de una
petición del usuario de la vista de las ausencias que tienen estudiantes y trabajadores
(Listado de Ausencias), el controlador AusenciasController es el encargado de construir
la misma, comprobando los requisitos de seguridad que permitirán al usuario acceder a
esta información, de ser posible el acceso muestra los datos de cada una de las
ausencias y si el usuario desea insertar una nueva ausencia, la vista Listado de
Ausencias contendrá un formulario para su registro., a continuación los nuevos datos
son validados y el controlador actualiza el modelo dela nueva ausencia, por último,
genera la vista para el Listado de Ausencias con los datos anteriormente registrados.
Ilustración 3.3: Diagrama de clase de Ausencia. (Visual Paradigm for UML 10.1)
55
3.3 Diagrama de secuencia
¿Qué es un diagrama de secuencia?
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia
temporal de eventos. En particular, muestra los objetos participantes en la interacción y
los mensajes que intercambian, ordenados según su secuencia en el tiempo. El eje
vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores
participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una
línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos.
El tiempo fluye de arriba-abajo. Un diagrama de secuencia (o varios) puede ilustrar las
interacciones entre los objetos para ejecutar un caso de uso. Los diagramas de
secuencia son particularmente importantes para los diseñadores debido a que ellos
aclaran los roles de los objetos en el flujo y por consiguiente brindan la entrada básica
para la determinación de las responsabilidades y las interfaces de las clases. (Ferré and
Sánchez, 2002)
En la Ilustración 3.4, para el caso de uso Gestionar Planificación (adicionar), se
evidencia la relación entre los objetos que intervienen en esta acción, donde el
Responsable de la planificación y control de la GOE es quien inicia y concluye esta
secuencia de acciones.
Ilustración 3.4: Diagrama de secuencia de Panificación. (Visual Paradigm for UML 10.1)
En la Ilustración 3.5, para el caso de uso Gestionar Ausencia (adicionar), se evidencia
la relación entre los objetos que intervienen en esta acción donde el Responsable de la
planificación y control de la GOE es quien inicia y concluye esta secuencia de acciones.
56
Ilustración 3.5: Diagrama de secuencia de Ausencia. (Visual Paradigm for UML 10.1)
3.4 Tratamiento de errores
La validación es una tarea importante en aplicaciones web. Los datos introducidos en
formularios se tienen que validar antes de escribirlos en una base de datos o pasarlos
a un servicio web. JQuery validation Engine es un plugin que ha sido desarrollado para
validar formularios en navegadores web. Este plugin incluye llamativas anotaciones en
caso de que el usuario ingrese datos incorrectos. Estos mensajes de error pueden ser
traducidos a cualquier idioma de modo que puede ser usado sin problemas. (Informativa,
2016)
Ilustración 3.6: Validación JQuery plugin. (Informativa, 2016)
57
3.5 Integración con LDAP
El Protocolo Ligero de Acceso a Directorio (Lightweight Directory Access Protocol,
LDAP) puede ser visto como un repositorio donde podemos colocar información para
después consultarla para su procesamiento. El repositorio se asemeja a una base de
datos, pero LDAP ha sido diseñada y optimizada para realizar operaciones de consulta.
(Gerardo and Fraga, 2006)
La universidad cuenta con un directorio de este tipo en el cual se encuentran registrados
todos los usuarios, por esta razón se decide que el acceso al sistema sea a través de
las credenciales de cada usuario en la red y el chequeo de los datos a través de métodos
de PHP para la obtención de información de este directorio.
Entre las funciones utilizadas se encuentra:
• ldap_connect(): establece una conexión con el servidor LDAP especificado en
nombre del host y puerto.
• ldap_bind(): se conecta al directorio con un determinado usuario y contraseña.
• ldap_search() realiza la búsqueda según el filtro especificado.
3.6 Diseño de la base de datos
Un modelo de datos es básicamente una “descripción” de algo conocido como
contenedor de datos (algo en donde se guarda la información), así como de
los métodos para almacenar y recuperar información de esos contenedores. Los
modelos de datos no son cosas físicas: son abstracciones que permiten la
implementación de un sistema eficiente de base de datos; por lo general se refieren
a algoritmos, y conceptos matemáticos.
El diseño de una base de datos es un proceso complejo que abarca decisiones a muy
distintos niveles. La complejidad se controla mejor si se descompone el problema en
varios problemas y se resuelve cada uno de estos problemas independientemente,
utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en
diseño conceptual, diseño lógico y diseño físico. (Informática, 2012)
3.6.1 Modelo conceptual de datos
Se utilizan para representar la realidad a un alto nivel de abstracción. Mediante los
modelos conceptuales se puede construir una descripción de la realidad fácil de
entender. Se utiliza para la abstracción de la base de datos, para construir una
descripción para entender en la realidad. (Informática, 2012)
58
A continuación la ilustración 3.7, muestra el modelo conceptual de los datos:
Ilustración 3.7: Modelo Conceptual de Datos. (Embarcadero ERStudio 8.0)
3.6.2 Modelo físico de datos
Es una descripción de la implementación de una base de datos
en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados
para tener un acceso eficiente a los datos. Por ello, el diseño físico depende del
SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición
de datos. Es una implementación de una base de datos en las estructuras de
almacenamiento y los métodos eficiente a los datos. Depende del SGBD concreto, y
se expresa de una manera más detallada (atributos, relaciones, etc.). (Informática,
2012)
59
En la Ilustración 3.8, se muestra el modelo físico de los datos:
Ilustración 3.8: Modelo Físico de Datos. (Embarcadero ERStudio 8.0)
3.7 Modelo de componentes y diagrama de despliegue
Un componente de software individual es un paquete de software, un servicio web, o un
módulo que encapsula un conjunto de funciones relacionadas (o de datos). Todos los
procesos del sistema son colocados en componentes separados de tal manera que
todos los datos y funciones dentro de cada componente estén semánticamente
relacionados. Debido a este principio, con frecuencia se dice que los componentes son
modulares y cohesivos. Los Modelos de Componentes ilustran las piezas del software,
controladores embebidos que conformarán un sistema. (Jacobson, Booch and
Rumbaugh, 2000)
60
El modelo de despliegue es un modelo de objetos que describe la distribuci6n física del
sistema en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo.
El modelo de despliegue se utiliza como entrada fundamental en las actividades de
diseño e implementación debido a que la distribución del sistema tiene una influencia
principal en su diseño. (Jacobson, Booch and Rumbaugh, 2000)
A continuación, se muestra el modelo de componentes y el diagrama de despliegue:
El modelo de componentes (Ilustración 3.9) y (Ilustración 3.10), muestra cómo está
dividido el sistema o parte de él, dentro de los componentes físicos están incluidos
archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables o paquetes.
Ilustración 3.9: Diagrama de Componentes Gestionar Planificación. (Visual Paradigm for UML
10.1)
Ilustración 3.10: Diagrama de Componentes Gestionar Ausencia. (Visual Paradigm for UML
10.1)
61
El Diagrama de despliegue (Ilustración 3.11) muestra la distribución en el sistema de los
distintos nodos que entran en la composición de la herramienta realizada y el reparto de
los programas que se ejecutan sobre estos nodos.
Ilustración 3.11: Diagrama de Despliegue. (Visual Paradigm for UML 10.1)
3.8 Conclusiones Parciales
En este capítulo se definieron elementos fundamentales en el proceso de elaboración
de la herramienta, partiendo de la arquitectura usada en la aplicación, una descripción
de las fundamentales clases del diseño y el manejo de errores implementado. También
se abordaron modelos fundamentales, como los modelos del diseño de la base de datos
y el de componentes, finalizando con la distribución del sistema una vez seleccionada
la herramienta como propuesta de solución.
62
Capítulo IV. Pruebas En el presente capítulo se describe la estrategia de pruebas a realizar y se muestran los
resultados de las mismas aplicadas a la herramienta informática desarrollada con el
objetivo de validar sus funcionalidades.
4.1 Casos de Pruebas (caja negra)
Las pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten
completamente todos los requisitos funcionales de un programa. En ellas se ignora
la estructura de control, concentrándose en los requisitos funcionales del sistema y
ejercitándolos.
Muchos autores consideran que estas pruebas de caja negra permiten encontrar,
funciones incorrectas o ausentes, errores de interfaz, errores en estructuras de datos
o en accesos a las bases de datos externas, errores de rendimiento, errores de
inicialización y terminación. (Pressman and Ph, 1997)
Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas la
Técnica de la Partición de Equivalencia. Esta técnica divide el campo de entrada en
clases de datos que tienden a ejercitar determinadas funciones del software. Por
otra parte, la Técnica del Análisis de Valores Límites prueba la habilidad del
programa para manejar datos que se encuentran en los límites aceptables y la
Técnica de Grafos de Causa-Efecto que permite al encargado de la prueba validar
complejos conjuntos de acciones y condiciones.
4.1.1 Pruebas de caja negra en casos de uso.
En este epígrafe se realizarán pruebas funcionales referentes a los casos de uso
más significativos que se hayan seleccionado.
En la Ilustración 4.1 se muestra la interfaz visual donde se introducen los datos del
nuevo estudiante para ser insertados en la base de datos.
Gestionar Estudiantes (Adicionar).
63
Ilustración 4.1: Adicionar nuevo estudiante. (Elaboración Propia)
a) Carnet de Identidad: Campo que admite solo números.
b) Nombre: Campo que admite solo letras.
c) Apellidos: Campo que admite solo letras.
d) Usuario: Campo alfanumérico.
e) Correo: Campo que admite una dirección de correo válida.
f) Carrera: Campo que admite solo letras.
64
Condición de entrada Clase de condición Clases válidas Clases inválidas
a) Carnet de Identidad Valor específico 1) Campo que admite solo
números.
2) En blanco.
3) Letras.
4) Caracteres especiales.
b) Nombre Valor específico 5) Campo que admite solo
letras.
6) En blanco.
7) Números.
8) Caracteres especiales.
c) Apellidos Valor específico 9) Campo que admite solo
letras.
10) En blanco.
11) Números.
12) Caracteres especiales.
d) Usuario Valor específico 13) Campo alfanumérico. 14) En blanco.
15) Caracteres especiales.
e) Correo Valor específico 16) Campo que admite una
dirección de correo válida.
17) En blanco.
18) Dirección invalida.
f) Carrera Valor específico 19) Campo que admite
solo letras.
20) En blanco.
21) Números.
22) Caracteres especiales.
Tabla 4.1: Clasificación de las condiciones de entrada. (Gestionar Estudiantes - adicionar)
Casos de prueba Clases Resultado
91100110263,
“Yordán Lázaro”,
“López Fernández”,
“yllfernandez”,
“Informática”
1, 5, 9,
13, 16,
19
OK
65
“Yordán”,
“”,
“123456789”,
“yllfernandez*”,
“”,
“”
3, 6, 11,
15, 17,
20
“”,
*,
;:,
“”,
“jcarlos”,
?
2, 8, 12,
14, 18,
22
Tabla 4.2: Juegos de datos. (Gestionar Estudiantes - adicionar)
66
4.2 Plan de pruebas de rendimiento
Las pruebas de rendimiento son una clase de pruebas que se implementan y se ejecutan
para caracterizar y evaluar las características relacionadas con el rendimiento del
destino de la prueba, como los perfiles de tiempo, el flujo de ejecución, los tiempos de
respuesta y la fiabilidad y los límites operativos. A lo largo del ciclo de vida del desarrollo
de software (SDLC), se implementan varios tipos de prueba de rendimiento, cada una
con un objetivo de prueba diferente. (IBM Corp, 2006)
Pruebas de Carga
Comprueba la aceptabilidad del comportamiento del rendimiento del destino de la
prueba en condiciones operativas variables (como el número de usuario, el número de
transacciones y etc.), mientras que la configuración permanece igual. (IBM Corp, 2006)
En la Ilustración 4.2 se muestran lo resultados de las pruebas ( Pruebas de Carga ) que
se le realizaron al sistema.
Ilustración 4.2: Prueba de Carga. (Apache-Jmeter-2.6)
Pruebas de Stress
Comprueba la aceptabilidad del comportamiento del rendimiento del destino de la
prueba cuando se producen condiciones extremas o anormales, como recursos
disminuidos o un número de usuarios extremadamente elevado. (IBM Corp, 2006)
En la Ilustración 4.3 se muestran lo resultados de las pruebas ( Pruebas de Stress ) que
se le realizaron al sistema.
67
Ilustración 4.3: Prueba de Stress. (Apache-Jmeter-2.6)
Pruebas de Rendimiento
Comprueba la aceptabilidad del comportamiento del rendimiento del destino de la
prueba utilizando diferentes configuraciones mientras las condiciones operativas
permanecen constantes. (IBM Corp, 2006)
En la Ilustración 4.4 se muestran lo resultados de las pruebas (Pruebas de Rendimiento)
que se le realizaron al sistema.
Ilustración 4.4: Prueba de Rendimiento. (Apache-Jmeter-2.6)
4.3 Conclusiones parciales del capítulo
En este capítulo se definieron puntos fundamentales de las pruebas realizadas al
sistema en los casos de uso seleccionados.
68
Conclusiones Como resultado de esta investigación se obtuvo una nueva herramienta informática que
permite automatizarla gestión de los procesos administrativos que se realizan para
garantizar el buen funcionamiento de la GOE en la UCLV, cumpliéndose de esta forma
con los objetivos planteados, con este fin:
• Se realizó un estudio del estado actual de la gestión de los procesos
administrativos de planificación y control de la GOE en varias facultades de la
UCLV y en particular en la facultad de Matemática Física y Computación.
• Se creó una base de datos para el control y persistencia de los datos manejados
en los procesos de planificación y control de la GOE.
• Se implementó una herramienta en un entorno web utilizando Symfony 3.3 como
plataforma de desarrollo, para realizar de forma ágil e interactiva tareas de
mediana complejidad.
• Se tomaron medidas para hacer segura y organizada la herramienta, de modo
que cada usuario es el encargado de realizar las tareas que le corresponden,
según el rol asignado en el sistema.
• Se realizaron las pruebas de caja negra a la herramienta, obteniéndose
resultados satisfactorios para las entradas seleccionadas.
69
Recomendaciones Se recomienda continuar con el estudio y perfeccionamiento de este software, para que
todas las áreas universitarias tengan el sistema automatizado, aumentando la eficiencia
de dicho control y disminuyendo posibles errores humanos, así como la optimización de
los algoritmos aplicados con el objetivo de brindar una mayor efectividad y desarrollo al
usuario.
70
Bibliografía
Alvarez, M. A. (2014) que-es-mvc. Available at: https://desarrolloweb.com/articulos/que-es-mvc.html.
Bakken, Stig Saether; Aulbach, Alexander; Schmid, Egon; Winstead, Jim; Torben, Lars Wilson; Lerdorf, Rasmus; Zmievski, Andrei; Ahto, J. (2002) ‘Manual de PHP’, p. 1719. Available at: http://www.opencontent.org/openpub/.
Bautista, A. (2012) Metodologia de la investigacion El objeto de estudio. Available at: https://es.slideshare.net/angelbautistaarellanes/capitulo-1-metodologia-de-la-investigacionel-objeto-de-estudio.
Becerril, J. (2015) Reglas de negocio Administrando la operación con reglas. Available at: https://sg.com.mx/revista/15/reglas-negocio-administrando-la-operacion-reglas.
E.V.A., U. (2017) ‘Flujo de Trabajo Modelo del Negocio EcuRed’. Available at: https://www.ecured.cu/Flujo_de_Trabajo_Modelo_del_Negocio.
Fernández, C. (2010) ‘El Proceso Unificado Rational para el Desarrollo de Software’, 2000. Available at: http://nuyoo.utm.mx/~caff/doc/El%5CnProceso%5CnUnificado%5CnRational.pdf.
Ferré, X. and Sánchez, M. (2002) ‘Desarrollo Orientado a Objetos con UML’, Facultad de Informática- UPM, 2, pp. 1–38.
Franklin, Jack; Devlin, I. (2013) ‘Beginning JQuery’, Springer.
García, A. (2008) ‘Gestión de las Universidades Públicas: La experiencia internacional’, pp. 1–32.
Gauchat, J. D. (2012) El gran libro de HTML5. CSS3 y Javascript, Journal of Chemical Information and Modeling. doi: 10.1017/CBO9781107415324.004.
Gerardo, L. and Fraga, D. (2006) ‘Administracion de Usuarios Con LDAP Y GNU Linux’.
Group, P. H. P. and others (2004) ‘Symfony guía definitiva’.
Gutierrez, N. (2011) DEFINICION CASO DE USO, ACTORES Y ROLES. Available at: http://nataliagutierrez9835ita.blogspot.com/2011/03/definicion-caso-de-uso-actores-y-roles.html.
IBM Corp (2006) Concepto: Prueba de rendimiento. Available at: https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/concepts/performance_testing_37A31809.html.
Informática, A. (2012) DISEÑO DE BASE DE DATOS INFORMÁTICA APLICADA. Available at: https://irfeyal.wordpress.com/bases-de-datos/modelamiento-de-bdd/.
Informativa, A. (2016) Plugins jQuery para validar formulario web. Available at: http://blog.aulaformativa.com/plugins-jquery-validar-formulario-web/.
Jacobson, I., Booch, G. and Rumbaugh, J. (2000) El proceso unificado de desarrollo de software.
James Rumbaugh, Ivar Jaconson, G. B. (1999) ‘El lenguaje unificado de modelado manual de referencia’.
Javier Eguiluz Pérez (2008) Introducción a CSS. Available at: http://librosweb.es/libro/css/.
Martínez, J. M. and Silva, C. A. (2010) ‘Anexo 2. Ingeniería de Requerimientos.pdf’.
71
Medina Basso, N. L. (2008) Gestión de ciencia e innovación tecnológica en las universidades: la experiencia cubana. Editorial Félix Varela. Available at: http://www.bases.unal.edu.co:2127/lib/unalbogsp/docDetail.action?docID=10219452&p00=gestión innovación.
Murcia, U. de (2011) ‘MANUAL BÁSICO de creación de páginas web’, Area de la Tecnologia de la informacion y las comunicaciones aplicadas, p. 57. Available at: https://www.um.es/atica/documentos/html.pdf.
Mvc, E. M. (2008) ‘El patrón MVC’, (Mvc).
Mysql, U. De (no date) ‘MySql-La Biblia De MySQL’.
Pressman, R. S. and Ph, D. (1997) Ingeniería del software.
Sommverville, I. (2005) ‘Ingenieria del Software 7ma. Ed.’, PEARSON EDUCATION. S.A. Madrid, p. 712.
Wikipedia (2018) Bootstrap framework. Available at: https://es.wikipedia.org/wiki/Bootstrap_(framework).
72
Anexos Anexo 1: Manual de Usuario
Documento Word adjunto.
Manual de Usuario (GOE).docx