departamento de computacio n

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)

https://es.wikipedia.org/wiki/Organizaci%C3%B3n

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


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


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


RF11.2: Eliminar un responsable de corte.


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


RF13.2: Eliminar un plan especial.


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


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


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


RF17.2: Adicionar un departamento.

El sistema debe permitir al usuario adicionar un departamento con los datos


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


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


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


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


de “Planificación”.



generar.


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




de “Planificación”.



insertar.


control de la GOE llena los campos y

acepta.


referentes a cada una de las planificaciones de los


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.


Flujos alternativos 1



acepta.


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.




acepta.


indica que algún campo contiene caracteres

incorrectos.

41



campos y acepta.

Flujo normal de los eventos. Sección C: Actualizar Planificación



control de la GOE selecciona una

planificación correspondiente a un

estudiante o un trabajador.


control de la GOE hace click en el ícono

“Editar”


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.






control de la GOE verifica que los

campos estén llenos y acepta.


indica que algún campo ha quedado vacío.







incorrectos.

42



campos estén correctos y acepta.

Flujo normal de los eventos. Sección D: Eliminar Planificación




planificación correspondiente a un




“Eliminar”.


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.


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




de “Ausencias”.

44



insertar.



acepta.


referentes a cada una de las ausencias de los


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.





acepta.



campos y acepta.


indica que existen campos vacíos.




acepta.



campos y acepta.



incorrectos.

Flujo normal de los eventos. Sección B: Actualizar Ausencia


45


control de la GOE selecciona un recurso

de los existentes hasta el momento.



“Editar”.



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.








campos estén llenos y acepta.


indica que algún campo ha quedado vacío.







campos estén correctos y acepta.



incorrectos.

46

Flujo normal de los eventos. Sección C: Eliminar Ausencia




ausencia correspondiente a un




“Eliminar”.


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.


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.


c) Apellidos Valor específico 9) Campo que admite solo

letras.

10) En blanco.

11) Números.


d) Usuario Valor específico 13) Campo alfanumérico. 14) En blanco.


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.


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”,

[email protected],

“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


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


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

departamento de computacio n

Documents