UNIVERSIDAD CATÓLICA DE CUENCA

UNIDAD ACADÉMICA DE INGENIERÍA DE SISTEMAS,

ELÉCTRICA Y ELECTRÓNICA

CARRERA DE INGENIERÍA DE SISTEMAS

PLATAFORMA INFORMÁTICA PARA LA GESTIÓN DE

INVESTIGACIÓN DE LA UNIVERSIDAD CATÓLICA DE CUENCA:

ADMINISTRACIÓN Y SEGURIDADES.

TRABAJO TEÓRICO – PRÁCTICO PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO DE SISTEMAS

CHRISTIAN RIGOBERTO ESTRADA ONCE

cestrada1990@outlook.com

Director: Ing. Msig. Diego Cordero Guzmán

2015

DECLARACIÓN

Yo, Christian Rigoberto Estrada Once declaro bajo juramento que el trabajo aquí

descrito es de mi autoría; que no ha sido previamente presentada para ningún grado o

calificación profesional; y, que he consultado las referencias bibliográficas que se

incluyen en este documento.

La Universidad Católica de Cuenca puede hacer uso de los derechos

correspondientes a este trabajo, según lo establecido por la ley de propiedad intelectual,

por su reglamento y la normatividad institucional vigente.

Christian Rigoberto Estrada Once

CERTIFICACIÓN

Certifico que el presente trabajo fue desarrollado por Christian Rigoberto Estrada

Once, bajo mi supervisión.

Ing. Msig. Diego Cordero Guzmán

AGRADECIMIENTOS

En primer lugar agradezco a Dios por brindarme la vida, salud, capacidad y

posibilidad de salir adelante en los objetivos y metas que me he planteado, superando

todos los obstáculos que se han presentado en el camino.

Después de largos años de estudio, de esfuerzos y de un proceso de formación

profesional, quiero agradecer a todos las personas que incondicionalmente me ayudaron

a ser una persona y profesional de bien.

Un agradecimiento especial al Ingeniero Diego Cordero Guzmán, por ser la persona

que me brindó todos sus conocimientos y colaboración para lograr esta meta.

De igual forma le agradezco a todos los docentes que me han brindado sus

conocimientos durante el periodo de estudio, los cuales han sido una base fundamental

para ejercer la profesión y ser una persona de bien.

DEDICATORIA

Con todo mi cariño y amor para mis padres por sus esfuerzos, sacrificios y todo lo

hicieron y pasaron para finalizar mis estudios y cumplir mis metas y sueños, por

guiarme y motivarme cada instante en mi vida a seguir adelante a pesar de cualquier

problema, obstáculo o circunstancia, por demostrarme que todo lo que uno se propone

se puede lograr con esfuerzo, dedicación e incluso lágrimas, por darme ánimos y fuerza

cuando pensaba que todo se terminaba y se venía todo contra de mí, a ustedes les estaré

la vida entera agradecidos con todo el corazón les agradezco con el alma.

María Alegría Once Pillajo

Juan Rigoberto Estrada Chiriboga

ÍNDICE DE CONTENIDO

DECLARACIÓN ....................................................................................................................................... II

CERTIFICACIÓN ................................................................................................................................... III

AGRADECIMIENTOS............................................................................................................................ IV

DEDICATORIA ........................................................................................................................................ V

ÍNDICE DE CONTENIDO ...................................................................................................................... VI

LISTA DE FIGURAS ............................................................................................................................... IX

LISTA DE TABLAS ............................................................................................................................... XII

LISTADO DE ANEXOS ....................................................................................................................... XIII

RESUMEN ............................................................................................................................................. XIV

ABSTRACT .............................................................................................................................................XV

1. CAPÍTULO 1. GENERALIDADES ............................................................................................ - 16 -

1.1. DEFINICIÓN DEL PROBLEMA .......................................................................................... - 16 -

1.2. ESTADO DEL ARTE ............................................................................................................ - 16 -

1.2.1. CONSEJOS PARA CONTROL DE ACCESOS AL SISTEMA ........................................ - 16 -

1.2.2. AMENAZAS EN LA SEGURIDAD INFORMÁTICA ..................................................... - 17 -

1.2.3. ATRIBUTOS DE APLICACIONES WEB (WEBAPPS) .................................................. - 17 -

1.2.4. TIPOS DE USUARIOS ...................................................................................................... - 18 -

1.2.5. SOFTWARE DE SEGURIDAD ......................................................................................... - 18 -

1.2.6. REQUISITOS MÍNIMOS DE SEGURIDAD INFORMÁTICA PARA LA

ADMINISTRACIÓN DE SISTEMAS .................................................................................................... - 21 -

1.2.7. TÉCNICAS PARA ASEGURAR EL SISTEMA ............................................................... - 22 -

1.3. DESCRIPCIÓN Y SUSTENTACIÓN DE LA SOLUCIÓN ................................................. - 23 -

2. CAPÍTULO 2. HERRAMIENTAS Y ARQUITECTURA DE DESARROLLO ..................... - 24 -

2.1. SELECCIÓN DE HERRAMIENTA ...................................................................................... - 24 -

2.2. ESPECIFICACIONES ........................................................................................................... - 25 -

2.3. MODO DE USO..................................................................................................................... - 26 -

2.4. ARQUITECTURA APLICADA PARA EL DESARROLLO DE LA SOLUCIÓN (DNA) - 27 -

2.4.1. ARQUITECTURA WINDOWS DNA ............................................................................... - 27 -

2.4.2. ARQUITECTURA TRES CAPAS ..................................................................................... - 27 -

2.4.3. PATRÓN MODELO VISTA CONTROLADOR (MVC) .................................................. - 28 -

2.4.4. TECNOLOGÍAS EN LA CAPA DE PRESENTACIÓN ................................................... - 29 -

2.4.5. TECNOLOGÍAS EN LA CAPA DE NEGOCIO ............................................................... - 30 -

2.4.6. TECNOLOGÍAS EN LA CAPA DE ACCESO A DATOS ............................................... - 30 -

2.4.7. ARQUITECTURA DEL SISTEMA ................................................................................... - 31 -

3. CAPÍTULO 3. ANÁLISIS ............................................................................................................ - 32 -

VII

3.1. MODELADO DEL NEGOCIO.............................................................................................. - 32 -

3.1.1. VISIÓN ............................................................................................................................... - 33 -

3.1.2. MISIÓN .............................................................................................................................. - 33 -

3.1.3. INTERESADOS ................................................................................................................. - 33 -

3.2. IDENTIFICACIÓN DE REQUERIMIENTOS ...................................................................... - 34 -

3.2.1. REQUERIMIENTOS NO FUNCIONALES ...................................................................... - 35 -

3.2.2. REQUERIMIENTOS FUNCIONALES ............................................................................. - 38 -

3.2.3. COMPORTAMIENTO DEL SISTEMA ............................................................................ - 50 -

3.2.4. PERSPECTIVA GENERAL DE LA APLICACIÓN ......................................................... - 50 -

3.2.5. DEFINIR EL ALCANCE ................................................................................................... - 51 -

3.2.6. CONTEXTO ....................................................................................................................... - 51 -

3.2.7. CASOS DE USO ................................................................................................................ - 51 -

3.3. ANÁLISIS DE LA SOLUCIÓN ............................................................................................ - 55 -

3.3.1. MODELADO DE CLASES ................................................................................................ - 55 -

3.3.2. MODELADO DE BASE DE DATOS ................................................................................ - 58 -

3.3.3. DICCIONARIO DE DATOS .............................................................................................. - 59 -

3.3.4. RELACIÓN DE DATOS .................................................................................................... - 67 -

3.3.5. DIAGRAMA DE BASE DE DATOS................................................................................. - 69 -

4. CAPITULO 4. DISEÑO ................................................................................................................ - 70 -

4.1. ARQUITECTURA DE MODELADO DE SERVICIOS ....................................................... - 70 -

4.2. DISEÑO DE INTERFAZ GRÁFICA .................................................................................... - 71 -

4.2.1. INTERFAZ DE INICIO DE APLICACIÓN ...................................................................... - 71 -

4.2.2. REGISTRO NUEVO USUARIO ....................................................................................... - 71 -

4.2.3. PANTALLA PRINCIPAL .................................................................................................. - 72 -

4.2.4. ESPECIFICACIÓN DE LAS DIVISIONES DE SUB CAPAS DE UNA VISTA ............. - 73 -

4.2.5. INDEX ................................................................................................................................ - 73 -

4.2.6. CREAR ............................................................................................................................... - 74 -

4.2.7. MODIFICAR ...................................................................................................................... - 74 -

4.2.8. ELIMINAR ......................................................................................................................... - 74 -

4.2.9. VER..................................................................................................................................... - 75 -

5. CAPITULO 5. IMPLEMENTACIÓN ......................................................................................... - 76 -

5.1. CONSTRUCCIÓN ................................................................................................................. - 76 -

5.1.1. ESPECIFICACIÓN DEL USO DE LA CAPA CONTROLADOR ................................... - 91 -

5.1.2. FUNCIÓN DE LA CAPA DE SERVICIOS ....................................................................... - 92 -

5.1.3. CAPA DEL MODELADO ................................................................................................. - 92 -

5.1.4. MODULO DE ADMINISTRACIÓN ................................................................................. - 92 -

5.1.5. MODULO DE GESTIÓN DE CONVOCATORIAS ......................................................... - 93 -

VIII

5.1.6. MODULO GESTIÓN UNIVERSITARIA ......................................................................... - 93 -

5.1.7. MODULO GESTIÓN DE PROYECTOS........................................................................... - 94 -

5.2. PROCESO DE INSTALACIÓN ............................................................................................ - 95 -

5.2.1. INSTALACIÓN DE JDK ................................................................................................... - 95 -

5.2.2. INSTALACIÓN DE NETBEANS ...................................................................................... - 98 -

5.2.3. INSTALACIÓN DEL SERVIDOR WEB TOMCAT....................................................... - 100 -

5.2.4. INSTALACIÓN DEL SERVIDOR DE BASE DE DATOS ............................................ - 106 -

5.2.5. CONFIGURACIÓN DE BASE DE DATOS.................................................................... - 109 -

5.2.6. INSTALACIÓN DE IREPORTS ...................................................................................... - 112 -

5.2.7. INSTALACIÓN DE IREPORTS EN NETBEANS .......................................................... - 118 -

5.3. PRUEBAS ............................................................................................................................ - 123 -

CONCLUSIONES .............................................................................................................................. - 128 -

RECOMENDACIONES .................................................................................................................... - 129 -

BIBLIOGRAFÍA ................................................................................................................................ - 130 -

LISTA DE FIGURAS

Fig. 1 Software Tivoli [5] ....................................................................................................... - 19 -

Fig. 2 Arquitectura Tivoli [5] ................................................................................................. - 21 -

Fig. 3 Arquitectura de Seguridad [10] .................................................................................... - 22 -

Fig. 4 Recomendaciones de Seguridad [12] ........................................................................... - 23 -

Fig. 5 Arquitectura Tres Capas [16] ....................................................................................... - 28 -

Fig. 6 Modelo Vista Controlador [17] .................................................................................... - 29 -

Fig. 7 Fases del Proceso Unificado Racional RUP [10] ......................................................... - 31 -

Fig. 8 Modelo De Procesos ...................................................................................................... - 32 -

Fig. 9 Contexto del Negocio ................................................................................................... - 33 -

Fig. 10 Análisis de Interesados ............................................................................................... - 34 -

Fig. 11 Simbología UML [3] .................................................................................................. - 35 -

Fig. 12 Requerimientos No Funcionales................................................................................. - 35 -

Fig. 13 Disponibilidad ............................................................................................................ - 36 -

Fig. 14 Escalabilidad .............................................................................................................. - 36 -

Fig. 15 Seguridad .................................................................................................................... - 37 -

Fig. 16 Requerimientos Funcionales ...................................................................................... - 38 -

Fig. 17 Administración de Permisos ....................................................................................... - 38 -

Fig. 18 Administración de Usuarios ....................................................................................... - 39 -

Fig. 19 Administración de Roles ............................................................................................ - 40 -

Fig. 20 Administración de Menús .......................................................................................... - 41 -

Fig. 21 Administración de Submenús .................................................................................... - 42 -

Fig. 22 Gestión de Proyectos .................................................................................................. - 43 -

Fig. 23 Gestión de Cronogramas ............................................................................................ - 44 -

Fig. 24 Gestión de Convocatorias ........................................................................................... - 45 -

Fig. 25 Gestión de Solicitudes ................................................................................................ - 46 -

Fig. 26 Administración de Carreras ........................................................................................ - 47 -

Fig. 27 Administración de Escuelas ....................................................................................... - 48 -

Fig. 28 Gestión de Niveles de Investigación .......................................................................... - 49 -

Fig. 29 Gestión de Tipos de Investigación ............................................................................. - 50 -

Fig. 30 Caso de Uso - Administración del Sistema ................................................................ - 51 -

Fig. 31 Caso de Uso - Administración de Escuelas y Carreras ............................................. - 52 -

Fig. 32 Caso de Uso - Gestión Tipos de Investigación ........................................................... - 53 -

Fig. 33 Caso de Uso - Gestión Niveles de Investigación ........................................................ - 53 -

Fig. 34 Caso de Uso - Gestión Proyectos ............................................................................... - 54 -

Fig. 35 Caso de Uso - Gestión de Reportería ......................................................................... - 54 -

Fig. 36 Modelo de Clases ....................................................................................................... - 55 -

Fig. 37 Módulo de Administración del Sistema ..................................................................... - 56 -

X

Fig. 38 Módulo de Gestión Universitaria ............................................................................... - 56 -

Fig. 39 Módulo de Convocatorias .......................................................................................... - 57 -

Fig. 40 Módulo Gestión de Solicitudes .................................................................................. - 58 -

Fig. 41 Módulo de Gestión de Proyectos ................................................................................ - 58 -

Fig. 42 Diagrama Base de Datos ............................................................................................ - 69 -

Fig. 43 Comunicación Capas De Arquitectura ....................................................................... - 70 -

Fig. 44 Interfaz Inicio De Aplicación ..................................................................................... - 71 -

Fig. 45 Interfaz Registro De Usuario ...................................................................................... - 72 -

Fig. 46 Interfaz Principal ........................................................................................................ - 73 -

Fig. 47 Formulario Index ........................................................................................................ - 73 -

Fig. 48 Formulario de Creación .............................................................................................. - 74 -

Fig. 49 Formulario de Modificación ....................................................................................... - 74 -

Fig. 50 Formulario de Eliminación ......................................................................................... - 74 -

Fig. 51 Formulario de Visualización ...................................................................................... - 75 -

Fig. 52 Componentes Módulo de Administración .................................................................. - 93 -

Fig. 53 Componentes Módulo Gestión Convocatorias .......................................................... - 94 -

Fig. 54 Componentes Módulo Gestión Universitaria ............................................................. - 94 -

Fig. 55 Componentes Módulo de Proyectos ........................................................................... - 95 -

Fig. 56 Instalación de JDK - Ejecutando el instalador........................................................... - 96 -

Fig. 57 Instalación de JDK - Pantalla Inicial .......................................................................... - 96 -

Fig. 58 Instalación de JDK - Selección de Herramientas ....................................................... - 96 -

Fig. 59 Instalación de JDK - Proceso de Instalación .............................................................. - 97 -

Fig. 60 Instalación de JDK - Instalación Finalizada ............................................................... - 97 -

Fig. 61 Verificación del JDK .................................................................................................. - 97 -

Fig. 62 Instalación Netbeans - Ejecución del Instalador......................................................... - 98 -

Fig. 63 Instalación Netbeans - Inicio de Instalación ............................................................... - 98 -

Fig. 64 Instalación Netbeans - Términos y Condiciones ........................................................ - 99 -

Fig. 65 Instalación Netbeans - Selección de Complementos .................................................. - 99 -

Fig. 66 Instalación Netbeans - Proceso de Instalación ........................................................ - 100 -

Fig. 67 Instalación Netbeans - Instalación Finalizada .......................................................... - 100 -

Fig. 68 Instalación Tomcat - Inicio de Instalación ............................................................... - 101 -

Fig. 69 Instalación Tomcat - Términos y Condiciones ......................................................... - 101 -

Fig. 70 Instalación Tomcat - Selección de Complementos................................................... - 102 -

Fig. 71 Instalación Tomcat - Configuración de Puertos ....................................................... - 102 -

Fig. 72 Instalación Tomcat - Ubicación del JRE 7 ............................................................... - 103 -

Fig. 73 Instalación Tomcat - Ubicación del Servidor Tomcat .............................................. - 103 -

Fig. 74 Instalación Tomcat - Iniciamos el Servidor .............................................................. - 104 -

Fig. 75 Comprensión de la Aplicación ................................................................................. - 105 -

Fig. 76 Iniciar Servicio Tomcat [22] .................................................................................... - 105 -

XI

Fig. 77 Instalación PostgreSQL - Ejecución de instalador ................................................... - 106 -

Fig. 78 Instalación PostgreSQL - Instalación de Componentes .......................................... - 106 -

Fig. 79 Instalación PostgreSQL - Ubicación de la Base de Datos ....................................... - 107 -

Fig. 80 Instalación PostgreSQL - Contraseña PostgreSQL ................................................. - 107 -

Fig. 81 Instalación PostgreSQL - Puerto PostgreSQL ......................................................... - 108 -

Fig. 82 Instalación PostgreSQL - Configuración Regional ................................................. - 108 -

Fig. 83 Instalación PostgreSQL - Proceso de Instalación .................................................... - 109 -

Fig. 84 Instalación PostgreSQL - Fin de Instalación ........................................................... - 109 -

Fig. 85 Configuración Base Datos - Ingreso de Password.................................................... - 110 -

Fig. 86 Configuración Base Datos - Crear Base de Datos .................................................... - 110 -

Fig. 87 Configuración Base Datos - Credenciales de Base de Datos ................................... - 111 -

Fig. 88 Configuración Base Datos - Creación Finalizada..................................................... - 111 -

Fig. 89 Configuración Base Datos - Ventana de Comandos ................................................ - 112 -

Fig. 90 Instalación Ireports – Ejecución ............................................................................... - 112 -

Fig. 91 Instalación Ireport – Inicio ....................................................................................... - 113 -

Fig. 92 Instalación Ireports - Términos y Condiciones......................................................... - 113 -

Fig. 93 Instalación Ireports – Características........................................................................ - 114 -

Fig. 94 Instalación Ireports – Dirección ............................................................................... - 114 -

Fig. 95 Instalación Ireports – Identificación ......................................................................... - 115 -

Fig. 96 Instalación Ireports – Proceso .................................................................................. - 115 -

Fig. 97 Instalación Ireports – Finalización ........................................................................... - 116 -

Fig. 98 Software Ireports ...................................................................................................... - 116 -

Fig. 99 Librería Postgresql – Ireports ................................................................................... - 117 -

Fig. 100 Driver Conexión PostgreSQL – Ireports ................................................................ - 117 -

Fig. 101 Credenciales Conexión PostgreSQl – Ireports ....................................................... - 118 -

Fig. 102 Netbeans Plugins .................................................................................................... - 119 -

Fig. 103 Netbeans Agregar Plugins ...................................................................................... - 119 -

Fig. 104 Plugins Ireport Netbeans ........................................................................................ - 119 -

Fig. 105 Interfaz Netbeans – Ireports ................................................................................... - 120 -

Fig. 106 Eliminación Plugin Ireports.................................................................................... - 120 -

Fig. 107 Crear Librería Netbeans ......................................................................................... - 121 -

Fig. 108 Jars a Cargar Netbeans ........................................................................................... - 121 -

Fig. 109 Agregar Nueva Librería Netbeans .......................................................................... - 121 -

Fig. 110 Importar Librería Netbeans .................................................................................... - 122 -

Fig. 111 Seleccionar Nueva Librería .................................................................................... - 122 -

Fig. 112 Librerias Importadas Netbeans ............................................................................... - 123 -

XII

LISTA DE TABLAS

TABLA I REQUERIMIENTOS DE DISPONIBILIDAD ..................................................... - 36 -

TABLA II REQUERIMIENTOS DE ESCALABILIDAD .................................................... - 36 -

TABLA III REQUERIMIENTOS DE SEGURIDAD ............................................................ - 37 -

TABLA IV REQUERIMIENTOS DE ADMINISTRACIÓN DE PERMISOS ..................... - 38 -

TABLA V REQUERIMIENTOS DE ADMINISTRACIÓN DE USUARIOS ...................... - 39 -

TABLA VI REQUERIMIENTOS DE ADMINISTRACIÓN DE ROLES ............................ - 40 -

TABLA VII REQUERIMIENTOS DE ADMINISTRACIÓN DE MENÚS ......................... - 41 -

TABLA VIII REQUERIMIENTOS DE ADMINISTRACIÓN DE SUBMENÚS ................ - 42 -

TABLA IX REQUERIMIENTOS DE GESTIÓN DE PROYECTOS ................................... - 43 -

TABLA X REQUERIMIENTOS DE GESTIÓN DE CRONOGRAMAS ............................ - 44 -

TABLA XI REQUERIMIENTOS DE GESTIÓN DE CONVOCATORIAS ........................ - 45 -

TABLA XII REQUERIMIENTOS DE GESTIÓN DE SOLICITUDES ............................... - 46 -

TABLA XIII REQUERIMIENTOS DE ADMINISTRACIÓN DE CARRERAS ................. - 47 -

TABLA XIV REQUERIMIENTOS DE ADMINISTRACIÓN DE ESCUELAS ................. - 48 -

TABLA XV REQUERIMIENTOS DE GESTIÓN DE NIVELES DE INVESTIGACIÓN .. - 49 -

TABLA XVI REQUERIMIENTOS DE GESTIÓN DE TIPOS DE INVESTIGACIÓN ...... - 50 -

TABLA XVII ENTIDADES .................................................................................................. - 59 -

TABLA XVIII LISTADO DE ATRIBUTOS ........................................................................ - 60 -

TABLA XIX LISTADO DE RELACIONES ......................................................................... - 67 -

TABLA XX PRUEBAS ADMINISTRACIÓN DEL SISTEMA ......................................... - 123 -

TABLA XXI PRUEBA GESTIÓN DE CARRERAS Y ESCUELA ................................... - 124 -

TABLA XXII PRUEBA GESTIÓN DE CONVOCATORIAS ........................................... - 124 -

TABLA XXIII PRUEBA GESTIÓN TIPOS DE INVESTIGACIÓN ................................. - 125 -

TABLA XXIV PRUEBA GESTIÓN NIVELES DE INVESTIGACIÓN ........................... - 125 -

TABLA XXV PRUEBA GESTIÓN DE PROYECTOS ...................................................... - 126 -

LISTADO DE ANEXOS

Anexo 1. Manual de Usuario Plataforma Informática Para La Gestión de Investigación de la

Universidad Católica de Cuenca.

RESUMEN

La Universidad Católica de Cuenca se encuentra involucrada en los nuevos procesos

establecidos por el estado Ecuatoriano para el desarrollo de proyectos de investigación

formativa por parte de los estudiantes y docentes de la universidad, para dar

cumplimiento con lo establecido se ha detectado que actualmente el control de estos

procesos es realiza de manera manual, por tal razón existen casos en los cuales se ha

detectado incumplimiento en los plazos de entrega y aprobación de los proyectos, de

esta manera surge la necesidad de un sistema que permita gestionar cada uno de los

procesos que se encuentren involucrados en la gestión de los proyectos de investigación.

Palabras Claves: Proyectos, proceso, gestión, webapps, framework, wizard.

XV

ABSTRACT

The Catholic University of Cuenca is involved in the new processes established

by the Ecuadorian state to develop formative research projects by students and docents

of the university, to comply with the provisions has been detected current control these

processes is performed manually, for this reason are cases in which there is failure in the

delivery and approval of projects, raising the need for a system that allows to manage

each of the processes that are involved in the management of research projects.

Keywords: Projects, process, management, webapps, framework, wizard.

- 16 -

1. CAPÍTULO 1. GENERALIDADES

1.1. DEFINICIÓN DEL PROBLEMA

El problema a resolver es el mínimo control y gestión que se lleva al momento de gestionar

proyectos de investigación por parte de la Universidad Católica de Cuenca, con la finalidad de

reducir y simplificar el tiempo de evaluación de un proyecto y en algunos casos la pérdida de

información, actualmente el proceso de evaluación de un proyecto es un proceso muy largo debido a

la cantidad de información que se debe procesar en cada facultad, como en el área de investigación e

incluso los tiempos de transmisión de la información es demasiado largo.

La importancia del proyecto se determina en el incremento de la productividad y el acceso a la

información en todo momento, lo que se conoce actualmente es que la forma en la que los procesos

son controlados es un trabajo que se hace de forma manual en el cual hay poco control debido al

gran volumen de información que se maneja.

1.2. ESTADO DEL ARTE

El tema de investigación en la cual está enfocado este proyecto y desarrollo de software es la

implementación de seguridad informática, con la finalidad de controlar las amenazas más

reconocidas para un sistema informático por ejemplo controlar los accesos al sistema, registro de

usuarios al sistema, evitar que los tipos de usuarios puedan hacer daño al sistema y por ende a la

integridad y confidencialidad de los datos.

Para el investigador Aguirre [1] la seguridad informática ha experimentado cambios rotundos en

los últimos 10 años, no solo en lo que concierne a la docencia, investigación y desarrollo, en el

medio profesional y en especial a los profesionales que desarrollan software escuchar y debatir a

diario los términos como: páginas web seguras, certificados digitales y de seguridad, firma

electrónica, protección de datos, detección de intrusos, cortafuegos, firewall, proxy, auditoria de

sistemas, log de datos y de acciones son normales.

En alguna etapa de la vida profesional sé pregunta que es, que se trata o que comprende la

seguridad informática, a tal punto en pensar que la seguridad informática está orientada a la

seguridad física como políticas de seguridad, planes de contingencia, metodologías, protección de

datos, gestión de accesos o auditorias, aunque la seguridad informática también abarca la seguridad

lógica en la cual influye la protección de la información dentro de su propio medio de generación,

transmisión, almacenamiento, usando por lo general técnicas y esquemas como la criptografía.

Para Aguirre [1], en conclusión el término seguridad informática a pesar que haya cientos de

definiciones, no es tratarlo como un producto sino un proceso que esta fusionado tanto con la

seguridad física como lógica los cuales se complementan, siendo esta una especialización de alto

nivel muy apreciada actualmente en el mercado laboral.

1.2.1. CONSEJOS PARA CONTROL DE ACCESOS AL SISTEMA

Para Sommerville [2] existen varios aspectos o consejos que pueden ayudar a mantener un

sistema con las seguridades estándares tales como:

Seguridad en los sistemas de cuenta: esto indica que el ingreso al sistema debe ser mediante un

nombre de usuario y contraseña, lo cual se controlará con la implementación de una pantalla de

inicio de sesión, así mismo en la creación de cuentas obligar al usuario a ingresar contraseñas

complejas validando una mínima cantidad de caracteres y la existencia de números. También existen

cuentas con vida limitada es decir cada cierto periodo de tiempo el sistema le va a obligar a cambiar

la contraseña, otro tipo de control es implementar un contador de ingreso erróneo de contraseña el

cual al cumplir un determinado número de intentos, el usuario será inactivado siendo el

- 17 -

administrador del sistema el único para activar el usuario nuevamente, otro consejo es inactivar los

usuarios ya sea por haber culminado su periodo de trabajo en la empresa, organización o entidad.

Control de password: el password es la medida más importante de seguridad en un sistema

informático ya que si algún usuario ya sea interno o externo logra destrozar esta barrera, el intruso

adquiere todo el acceso al sistema con lo cual significa que la información del sistema este

vulnerable y expuesta a cualquier modificación, consulta o eliminación.

Evitar la vulnerabilidad: implementar controles cuya intención es garantizar que los ataques no

tengan éxito esto con la implementación de datos encriptados.

1.2.2. AMENAZAS EN LA SEGURIDAD INFORMÁTICA

Según el investigador [2] las amenazas han ido evolucionando en el transcurso del tiempo antes

tenían un ámbito limitado, pero ahora con la implementación de software en la web estas amenazas

han evolucionado causando una diversidad de inconvenientes, ya que se pueden presentar como

virus o algoritmos que se ejecutan automáticamente, los cuales están programados para la obtención

de contraseñas y uso sin autorización de servicios del sistema. Por estas circunstancias para un

sistema la seguridad es la ámbito más importante de confiabilidad del sistema.

En cualquier sistema en red, existen tres principales tipos de amenazas a la seguridad las cuales

son:

Amenazas a la Vonfiabilidad del Sistema y sus Datos: es decir pueden difundir datos a individuos

o programas que no están autorizados a tener acceso al sistema [3].

Amenazas a la Integridad del Sistema y sus Datos: lo cual está ligado a las amenazas que pueden

dañar o corromper el software o sus datos [3].

Amenazas a la Disponibilidad del Sistema y sus Datos: dichas amenazas pueden restringir el

acceso al software [3].

1.2.3. ATRIBUTOS DE APLICACIONES WEB (WEBAPPS)

Como se sabe las aplicaciones web son un conjunto de distintos enfoques, prácticas, soluciones y

aplicaciones, por tal motivo Presmman [3] nos presenta los siguientes atributos:

Uso Intensivo de Redes: una webapp puede estar acoplada en un ámbito muy grande y complejo

como es el internet en el cual va a interactuar con distintos tipos de usuarios, así mismo una webapp

podrá estar ligada a una red limitada como una intranet corporativa.

Concurrencia: hace referencia al número de conexiones o peticiones que recibirá la aplicación

web las cuales varían dependiendo del acceso a los módulos de un sistema.

Carga Impredecible: hace relación al número de usuarios que accederán al sistema, siendo esta

característica impredecible ya que un día pueden ser 10 usuarios y a la semana siguiente podrían

llegar a 100 usuarios.

Rendimiento: es uno de los atributos principales que debe poseer una webapp ya que el usuario

final busca una interacción, comunicación y procesamiento eficiente y eficaz para realizar una

transacción sea esta ingresar al sistema, procesamiento de datos, consulta, etc.

Disponibilidad: es un atributo primordial ya que el usuario espera y anhela una disponibilidad del

100% es decir un periodo de 24 horas los 365 días del año.

Orientadas a los Datos: la función principal de las webapps es acceder a la información que

existe en base de datos localizadas en algún lugar del mundo, los datos consultados pueden ser

visualizados u obtenidos en forma de texto y gráficos.

Contenido Sensible: la calidad y naturaleza estética, presentación y distribución del contenido

constituye un factor importante en la calidad de una webapp.

- 18 -

Evolución Continua: a diferencia de las aplicaciones de escritorio que evolucionan en etapas

planeadas cronológicamente, las aplicaciones web evolucionan en forma continua.

Seguridad: es el atributo y función más importante debido a que las webapps se encuentran

disponibles a todo tipo de usuarios mediante el acceso a una red, basado esto es difícil o imposible

limitar la población de usuarios finales que pueden acceder a la aplicación, en base a estos se debe

proteger el contenido sensible y brindar modos seguros de transmisión de datos con la ayuda de

implementación de infraestructura y métodos de control en la misma aplicación.

1.2.4. TIPOS DE USUARIOS

Todo desarrollador de software, está consciente que existen varios tipos de usuarios con los que

el sistema tendrá que lidiar el día a día, por lo que se tiene la obligación de considerar las

habilidades, ventajas, desventajas y virtuales que poseen los diferentes tipo de usuarios que estarán

inmersos en la aplicación.

Para el investigador [4] el usuario es un conjunto de permisos y de recursos a los cuales se tiene

acceso, es decir un usuario puede ser tanto una persona como una máquina, para tener una idea más

amplia de los tipos de usuarios se detallarán a continuación:

Usuario Administrador: es la persona que goza de todos los permisos y accesos, además es

aquella quien conoce el sistema completamente.

Usuario Registrado: se denomina así a la persona que tiene derechos especiales en algún

servicio, programa o aplicación mediante la acreditación de un identificador y clave de acceso,

basados en un registro de usuario previo.

Usuario Anónimo: es aquel que navega en sitios web sin autenticarse.

Usuario beta tester: este tipo de usuario es utilizado en el proceso de desarrollo de software, es

aquel que se encuentra entre el desarrollador y el usuario final, es el encargado de comprobar y

programar, siendo su tarea de reportar al desarrollador los errores o sugerencias detectadas.

Según el conocimiento del investigador [4] las personas que tienen contacto directo con las

computadoras pueden ser definidas en otro grupo de usuarios ya que es necesario clasificarlos según

su nivel de conocimiento, los cuales están clasificados de la siguiente manera:

Inexpertos: son personas o usuarios que no tienen experiencia en el uso de máquinas y

tecnología, algo que es muy raro encontrar hoy en día por el crecimiento tecnológico.

Principiantes: personas que han tenido algún contacto o conocimiento con la tecnología.

Habilitados: son usuario capacitados, pero que les falta algo (nivel de competencia o

comprensión), se podría decir que la mayoría de los usuarios entran en esta categoría.

Expertos: se trata de individuos que poseen vasto conocimiento sobre tecnología.

1.2.5. SOFTWARE DE SEGURIDAD

Existe una diversidad de software dedicado a la seguridad, en este indicaremos las funciones que

posee el software Tivoli:

- 19 -

Fig. 1 Software Tivoli [5]

Para [5] la solución de control de accesos e identidades ofrece un acceso de usuario autorizado a

los sistemas, aplicaciones y datos, mejoran la experiencia de los usuarios, dan soporte a la

conformidad, y aumentan la confianza en la identidad de las personas.

Las soluciones de conformidad de la seguridad ofrecen completas funciones para:

Gestión de Identidades: gestiona las identidades y derechos de usuarios para acceder a los

recursos para gestionar las identidades y los accesos de forma eficaz.

Gestión de Accesos: El control de accesos proporciona un acceso a tiempo (tiempo de sesión

abierta de un usuario) ya sea en entornos múltiples como en dominios de seguridad, aplica políticas

de seguridad y protege de las amenazas externas.

Productos disponibles de control de accesos e identidades.

IBM Tivoli Identity and Access Manager: Ofrece una gestión eficaz de los usuarios y un control

de accesos para los usuarios internos y externos, mediante la gestión de las cuentas de usuario,

permisos de acceso y contraseñas.

IBM Tivoli Unified Single Sign-On (UK): Simplifica y automatiza el inicio de sesión en las

aplicaciones de la organización en las aplicaciones web y en las aplicaciones.

IBM Tivoli Access Manager for e-business: Es un centro de autenticación y de autorización para

aplicaciones web, centraliza el control de accesos y presenta las aplicaciones de manera segura y

eficaz.

Seguridad de la información y los datos

La seguridad de la información y los datos consiste en permitir la colaboración y al mismo

tiempo gestionar los riesgos a través de un enfoque, que conserve al mismo nivel de disponibilidad,

confidencialidad e integridad de la información.

Las soluciones de seguridad de los datos proporcionan completas funciones para la protección de

datos y la gestión de accesos, que se pueden integrar para lograr seguridad en todo el sistema con:

Gestión de claves y cifrado de datos.

Almacenamiento seguro y archivado para la retención de datos.

Servicios para evaluar, proteger, supervisar y gestionar la información.

La seguridad de las aplicaciones.

Para proporcionar un software de seguridad se obtiene mediante la autentificación y la

autorización de usuarios válidos, y la protección de las aplicaciones web.

- 20 -

Cada vez más, la opción escogida son aplicaciones web para nuevos servicios. Se debe centrar en

la seguridad de estas aplicaciones con el fin de proteger la información confidencial [6].

El software de seguridad debe proteger sus aplicaciones de forma activa y preventiva ante amenazas

externas e internas, con uno de los siguientes tipos de seguridad:

Seguridad de red preventiva.

Seguridad del ciclo de vida de las aplicaciones y procesos seguros.

Gestión de accesos para proteger la información fundamental de los clientes.

Productos destacados de seguridad de aplicaciones [5].

IBM Tivoli Data & Application Security: Para autorizaciones precisas de uso de aplicaciones,

gestión centralizada de políticas de seguridad y ciclo vital de claves de cifrado.

IBM Tivoli Federated Identity Manager: Ofrece un inicio de sesión centrado en el usuario para

compartir de forma segura la información y simplificar la integración de las aplicaciones.

IBM Tivoli Compliance Insight Manager: Ofrece seguridad a una organización mediante la

supervisión de actividades de los usuarios en toda la empresa.

Conformidad de la seguridad

Incluye identificar, priorizar, y gestionar la empresa teniendo en cuenta personas, procesos,

información y tecnología para alcanzar dichos objetivos. Estas soluciones incluyen funciones que

dan soporte a todo el ciclo de vida, ya que supervisan y mantienen la conformidad empresarial [7].

Las soluciones de conformidad de la seguridad ofrece funciones para:

Evaluar, analizar y gestionar los riesgos.

Automatizar la política de conformidad de la seguridad con controles internos.

Supervisar y realizar informes para lograr conformidad.

Productos destacados de conformidad de la seguridad

Tivoli Key Lifecycle Manager: Permite a las organizaciones gestionar las claves de cifrado ya que

simplifica, centraliza, automatiza y refuerza los procesos de gestión de claves en el entorno del

sistema informático.

Tivoli Security Compliance Manager: Protege las configuraciones vulnerables de software, ya

que identifica el incumplimiento de seguridades.

- 21 -

Fig. 2 Arquitectura Tivoli [5]

1.2.6. REQUISITOS MÍNIMOS DE SEGURIDAD INFORMÁTICA PARA LA

ADMINISTRACIÓN DE SISTEMAS

Para Santander [8] se debe tener en cuenta el crecimiento de Tecnologías de la Información con

el fin de controlar los riesgos tecnológicos y contar con políticas y normas de seguridad informática

para brindar un ambiente seguro y adecuado.

Se debe tener aclaro los siguientes aspectos:

Características y Criterios de la Información: Los datos deben contener un alto grado de

seguridad y cumplir con los siguientes criterios:

Confiabilidad, Confidencialidad, Integridad, Disponibilidad, Efectividad, Eficiencia y

Cumplimiento

Administración de Usuarios: este punto comprende la Administración de privilegios de acceso a

sistemas, Administración de password, Asignación y responsabilidad de software.

Desarrollo de programas, sistemas o aplicaciones.

Contar con la organización y personal adecuado, con conocimiento y experiencia en el desarrollo

de sistemas.

La estructura tecnológica, sistemas operativos y herramientas de desarrollo, que se utilizarán

deberán estar debidamente licenciados por el fabricante o representante del software [9].

- 22 -

Fig. 3 Arquitectura de Seguridad [10]

1.2.7. TÉCNICAS PARA ASEGURAR EL SISTEMA

Para [10] lo más importante que se posee es la información, por lo tanto, deben existir técnicas

que la protegan. Estas técnicas brindan la seguridad lógica que consiste en la aplicación de barreras y

procedimientos que resguardan el acceso a los datos y solo permiten acceder a ellos a las personas

autorizadas.

A continuación se enumeran una serie de medidas que se consideran básicas para asegurar un

sistema:

Según [11] utilizar técnicas de desarrollo que cumplan con los criterios de seguridad partiendo de

estándares y personal con conocimientos y formación adecuada.

Codificar la información: criptología, criptografía y criptociencia.

Contraseñas difíciles de averiguar y que se cambien con la suficiente periodicidad.

Asegurar que los recursos del sistema de información sean utilizados de la manera que se decidió

y que el acceso a la información allí contenida sólo sea posible a las personas que se encuentren

acreditadas.

- 23 -

Fig. 4 Recomendaciones de Seguridad [12]

1.3. DESCRIPCIÓN Y SUSTENTACIÓN DE LA SOLUCIÓN

La investigación busca definir y establecer un sistema informático con la implementación de un

módulo de Administración y Seguridad el cual permita agilizar, controlar y garantizar la

confiabilidad de los datos los cuales están orientados a los proyectos de investigación de la

Universidad Católica de Cuenca, identificando cada uno de los niveles de seguridad, roles, permisos

o accesibilidad al sistema acorde al tipo de usuario que ingresa al sistema, gestionar debidamente el

ingreso al sistema y poseer un registro de LOG (Historial de Acciones) eficiente, con la finalidad de

conocer con exactitud las acciones realizadas, para procedimientos de auditoría o respaldo para

procesos propios que la Universidad considere necesarios.

Con el presente trabajo se busca implementar los Niveles de Seguridad, Parametrización del

Sistema, Roles, Privilegios y Creación de Usuarios, por lo cual se debe diseñar un sistema

informático que cumpla cada uno de los estándares de Administración y Seguridad de Software

según las necesidades y requerimientos especificados por el Área de Investigación.

La investigación tomará como referencia y base de estudio el Área de Investigación de la

Universidad Católica de Cuenca para entender adecuadamente la Administración y Seguridad que

existe normalmente, con el propósito de implementarlos en el sistema informático, una vez

finalizado y aprobado el sistema, se realizarán las pruebas correspondientes por el personal del Área

de Investigación asignada a la Facultad de Ingeniería de Sistemas, Eléctrica y Electrónica de la

Universidad Católica de Cuenca, con la finalidad de aprovechar al máximo los distintos beneficios

que ofrecerá el sistema informático.

- 24 -

2. CAPÍTULO 2. HERRAMIENTAS Y ARQUITECTURA

DE DESARROLLO

2.1. SELECCIÓN DE HERRAMIENTA

En [13] determina que es importante tomar en cuenta el proyecto como un todo y tener una visión

estratégica. La consigna es identificar cómo podemos montar un sistema que nos retroalimente y

permita que la organización efectivamente se despliegue y crezca en base al desarrollo individual.

Esto se logra con un buen modelo de gestión de conocimiento, que elimine el anonimato y promueva

la meritocracia en la organización. Por esta razón se recomienda tener claro estos elementos antes de

definir con qué solución tecnológica se abordarán los procesos formativos en una empresa.

El primer enfoque para seleccionar una herramienta informática según [13] es analizar si la

organización cuenta con los requisitos imprescindibles: recursos humanos y financieros. En el área

de recursos humanos, se necesitará contar con diversos perfiles capacitados para organizar un

equipo de formación virtual competente: líder de proyecto, tecnólogo, diseñador, profesores y

tutores. Con respecto a lo financiero, se deberá considerar un gasto inicial para adquirir tecnología y

formación, siendo éste una inversión recuperable en el futuro.

Para América [13] el segundo enfoque para seleccionar una herramienta apropiada es entender

claramente el caso de negocio. Por caso de negocio, se refiere a entender y definir con los actores

más importantes de la organización qué es lo que se busca con la incorporación de soluciones

tecnológicas.

El autor [13], recomienda efectuar un análisis adecuado de consultoría, que permita responder a

las necesidades y objetivos establecidos en la organizacion para desarrollar un proceso de gestión. Es

vital preguntarle al cliente si precisa una plataforma sencilla de administrar y utilizar; si espera una

herramienta con diversidad de configuración y funcionalmente modular; o si simplemente desea que

sus usuarios se autentifiquen para navegar o acceder por los diferentes módulos y contenidos del

sistema para luego obtener sus reportes de seguimiento. Luego de obtener estas respuestas, será el

momento de evaluar los sistemas que resuelvan los requerimientos identificados y proponer opciones

al cliente.

Finalmente América [13] propone centrarse en los recursos que van a ser necesarios, analizando

previamente el equipo de personas, infraestructura y equipamiento disponible, para asegurar una

buena gestión del ciclo de vida de la tecnología seleccionada. Estas variables van a orientar la

decisión hacia soluciones tercerizadas o desarrollo de proyectos internos.

Tomando en cuenta los enfoques antes descritos la forma idónea para seleccionar las

herramientas adecuadas es evaluar a las diferentes plataformas en base a los siguientes criterios:

Grado de madurez, grado de actividad de la comunidad, disponibilidad de librerías, aplicaciones de

terceros, compatibilidad con el resto de plataformas, rendimiento y escalabilidad.

Para seleccionar las herramientas de software que más se acople a las necesidades de la

Universidad Católica de Cuenca, debemos conocer estrictamente las limitaciones que existen en la

institución en lo que concierne a hardware para la implementación de ciertas herramientas, como

desarrolladores de software debemos tener la capacidad de encontrar los recursos adecuados para la

creación de un sistema.

Cuando hay requerimientos específicos sobre qué tipo de herramientas se debe utilizar, se debe

justificar las razones, las cuales motivaron a seleccionar y utilizar cierta herramienta, en nuestro

medio, en especial la Universidad Católica de Cuenca concretamente la Facultad de Ingeniería de

Sistemas, Eléctrica y Electrónica está orientada al desarrollo de software utilizando sistemas de

ambiente libre, con estas herramientas se evitará costos elevados destinados al licenciamiento del

- 25 -

software, por lo cual la Universidad Católica de Cuenca directamente el Área de Investigación, ha

optado por establecer como requisito primordial utilizar herramientas de software libre.

Teniendo en cuenta los requerimientos antes mencionados por el Departamento de Investigación

de la Facultad de Sistemas se ha optado para el desarrollo de software el lenguaje de programación

JAVA utilizando la plataforma Netbeans complementado con el framework de desarrollo

PrimeFaces, el cual contiene gran cantidad de componentes que facilitan el desarrollo de una manera

fácil, eficaz y sin limitación alguna, de igual manera para la gestión y almacenamiento de la

información se utilizará el gestor de base de datos denominado PostgreSQL, con lo cual cumplimos

estrictamente los requisitos antes establecidos, el cual es implementar el sistema con la utilización de

herramientas en ambiente libre.

Para definir el modelado de datos se utilizará la herramienta CASE Visual Paradigm 11.2, la cual

es una herramienta para el modelado de datos, componentes y formas existentes, así mismo para

definir la estructura de base de datos, generación de tablas y sus atributos se utilizará la herramienta

CASE Studio 2 de ambiente libre, la principal característica de este software es su gran

compatibilidad y soporte técnico que brinda con el gestor de base de datos PostgreSQL, gracias a

ésta herramienta se puede generar una base de datos de forma rápida y sencilla, mediante la

ejecución de un script.

2.2. ESPECIFICACIONES

JAVA es un lenguaje de programación de propósito general y concurrente, el cual permite

desarrollar aplicaciones para diferentes entornos, tales como desktop, web y Mobile, JAVA está

basado en clases con la finalidad de tener mínimas dependencias de implementación como fuera

posible. Su intención es permitir a los desarrolladores de aplicaciones escribir el programa una sola

vez y lo ejecuten en cualquier dispositivo, es decir, el código que es ejecutado en una plataforma no

tiene que ser recompilado para funcionar en otra. JAVA a partir del 2012 hasta la actualidad es uno

de los lenguajes de programación con más demanda para el desarrollo de aplicaciones,

particularmente para software Cliente-Servidor por la accesibilidad, ventajas, complementos y

frameworks que nos facilitan.

Para ORACLE [14], JAVA es una tecnología que se usa para el desarrollo de aplicaciones

orientadas a la Web con elementos más interesantes y útiles. Java no es lo mismo que JavaScript,

que se trata de una tecnología sencilla que se usa para crear páginas web y solamente se ejecuta en el

explorador.

La primera característica de JAVA según [10], es la orientación a objetos (OO), se refiere a un

método de programación y al diseño del lenguaje. Aunque hay muchas interpretaciones para

orientación a objetos, una primera idea es diseñar el software de forma que los distintos tipos de

datos que usen estén unidos a sus operaciones. Así, los datos y el código (funciones, métodos o

clases) se combinan en entidades llamadas objetos. Un objeto puede verse como un paquete que

contiene el comportamiento, es decir, el código fuente y los datos. El principio fundamental es

separar aquello que cambia de las cosas que permanecen inalterables. Frecuentemente, cambiar una

estructura de datos implica un cambio en el código que opera sobre los mismos, o viceversa. Esta

separación en objetos coherentes e independientes ofrece una base más estable para el diseño de un

sistema software. El objetivo es hacer que grandes proyectos sean fáciles de gestionar y manejar,

mejorando su calidad y reduciendo el número de proyectos fallidos. Otra de las grandes promesas de

la programación orientada a objetos es la creación de entidades más genéricas denominado como

objetos, que permitan la reutilización del software entre proyectos.

La segunda característica que [10] analizará es la independencia de la plataforma, lo cual

significa que programas escritos en lenguaje Java pueden ejecutarse en cualquier tipo de hardware y

- 26 -

dispositivo, tales como: Servicios Web, Servlets y Java Beans, tal como especifica el axioma de

Java, “Escriba Una Vez, Ejecútelo En Cualquier Lugar”.

Por las razones expuestas anteriormente y por el requerimiento estricto por parte de la

Universidad Católica de Cuenta en su Departamento de Investigación de utilizar plataformas de

ambiente libre, se decide emplear tecnología JAVA, con la finalidad de desarrollar una aplicación

web Cliente-Servidor, el cual estará escrito, depurado y ejecutado en la plataforma IDE llamada

Netbeans.

Para inclinarse por un determinado gestor de base de datos se debe tener en consideración

características de mayor importancia, a parte de las mencionadas anteriormente, tales como la alta

concurrencia, limitaciones, confiabilidad, licenciamiento, multiplataforma y debe ser diseñado para

soportar grandes volúmenes de almacenamiento.

Para seleccionar el motor de base de datos idóneo por la magnitud de datos que serán

almacenados y cual cumpla con las características fundamentales como estabilidad, potencia,

robustez, facilidad de administración e implementación de estándares es PostgreSQL, el cual es

totalmente compatible con JAVA e incluso posee, en su entorno de desarrollo componentes que

permiten la comunicación con la base de datos de una manera sencilla y al combinar con Primefaces

el uso se convierte más intuitivo y dinámico, lo cual significa que el desarrollo del sistema se

enfocará a la lógica del negocio, antes que la comunicación con la base de datos y su interacción.

Para Humberto [15] el gestor o administrador de base de datos PostgreSQL es el idóneo ya que

posee amplia información en temas de soporte ya que existe una importante comunidad de

profesionales y aficionados que brindan soluciones en tiempo real, además de esto ahorra

considerables costos de operación, ya que PostgreSQL ha sido diseñado para tener un mantenimiento

y ajuste mucho mejor, conservando todas las características estabilidad y rendimiento.

Además para [15], PostgreSQL tiene la capacidad de ser extensible es decir que su código fuente

está disponible para todos sin costo.

La base de datos PostgreSQL es un motor que fue creado para manejar magnitudes de

almacenamiento masivo, además es totalmente compatible y es adecuado para las tecnologías,

aplicaciones y programas web, una de sus ventajas es que su sintaxis SQL es estándar y fácil de

aprender, es multiplataforma, tiene la ventaja de replicación de datos y sobre todo el uso de memoria

es mínimo

2.3. MODO DE USO

Para el desarrollo de la aplicación web que se implementará en la Universidad Católica de

Cuenca precisamente en la Facultad de Ingeniería de Sistemas, Eléctrica y Electrónica se utilizará el

IDE de programación Netbeans con JDK 7 (Java Developer Kit) que es un software que provee

herramientas de desarrollo para la creación de programas Java, el cual se complementará con la

tecnología de JavaServer Faces (JSF), esta tecnología es un framework para aplicaciones JAVA

basadas en web que simplifica el desarrollo de interfaces de usuario en las aplicaciones, JSF utiliza

JavaServer Page (JSP) como la tecnología que permite hacer el despliegue de las páginas web,

además de estos se instalará el componente llamado Primefaces, quien brindará un marco de

interfaces graficas que permiten la elaboración de páginas con tecnología Ajax, HTML, JavaScript y

XHTML, este framework dispone de una gran cantidad de componentes de creación de software, los

cuales permiten un desarrollo de la aplicación web de manera rápida, amigable, eficaz y eficiente.

El entorno de desarrollo Netbeans ofrece gran variedad y facilidad de integración con

PostgreSQL, utilizando un componente denominado Entity Classes From Database, en el cual solo

se tiene que especificar la cadena de conexión a la base de datos y este componente crea las

entidades en las cuales se va a trabajar directamente, éstas herramientas las cuales se ha detallado

son totalmente compatibles con Windows y Linux.

- 27 -

Para lograr un funcionamiento correcto de la aplicación es necesario implementar un servidor

web, por lo general Netbeans posee el servidor web Glasfish, pero éste no es apropiado y compatible

con Primefaces, por lo que se implementará el servidor web Apache Tomcat, el cual es

multiplataforma, el funcionamiento de este servidor web es un contenedor de servlets brindando la

facilidad de implementar las especificaciones de JavaServer Pages.

2.4. ARQUITECTURA APLICADA PARA EL DESARROLLO DE

LA SOLUCIÓN (DNA)

Para [16] la arquitectura DNA (Aplicaciones de Internet distribuida) está diseñada para

solucionar problemas que no involucren al usuario. Es decir, que se construyan soluciones rápidas

por los especialistas en los servidores, sin complicar ni al usuario ni su máquina.

Según [16] implementar soluciones basadas en DNA involucra crear aplicaciones divididas en

capas funcionales que se comunican entre sí. Este concepto por sí mismo no significa nada nuevo,

pero DNA provee protocolos estándares e interfaces pre-implementadas que permiten al

desarrollador de software concentrarse en construir la lógica del sistema, sin preocuparse por como

las partes se intercomunican.

2.4.1. ARQUITECTURA WINDOWS DNA

Windows DNA es la primera arquitectura de aplicación que contiene e integra totalmente los

modelos Web para el desarrollo de aplicaciones para cliente o servidor.

Al utilizar el modelo Windows DNA, se construyen aplicaciones de negocios modernas,

escalables, multicapas, para ser ejecutadas sobre cualquier tipo de red. Las aplicaciones Windows

DNA mejoran el flujo de información dentro y fuera de la organización, son dinámicas y flexibles al

cambio por las necesidades del negocio, se integran fácilmente con los sistemas y datos existentes.

Windows DNA incluye productos y servicios para ayudar a los desarrolladores a implementar los

servicios de las aplicaciones de tres capas basadas en componentes. La arquitectura de tres capas es

recomendada para construir aplicaciones distribuidas escalables. Los componentes son

recomendados como una vía para construir soluciones flexibles y de fácil mantenimiento.

Una de las principales ventajas de Windows DNA es Internet, que ha cambiado dramáticamente

el panorama de la computación. Cinco años atrás, el proceso de desarrollo de aplicaciones ejecutado

por una persona en una computadora era relativamente informal. En contraste, algunas de las

aplicaciones más poderosas de nuestros días soportan miles de usuarios simultáneos, necesitan estar

corriendo las 24 horas del día y deben ser accesibles desde una amplia variedad de dispositivos,

desde computadoras portátiles hasta estaciones de trabajo de alto desempeño.

Para satisfacer estos requerimientos imperativos, los desarrolladores de aplicaciones necesitan

adecuar herramientas de planificación y guías de cómo incorporar las tecnologías apropiadas.

2.4.2. ARQUITECTURA TRES CAPAS

La arquitectura de una aplicación es la vista conceptual de la estructura de esta. Toda aplicación

contiene código de presentación, procesamiento de datos y de almacenamiento de datos. La

arquitectura de las aplicaciones difiere según como está distribuido este código.

La arquitectura DNA habla sobre Universal Data Access (Acceso Universal a Datos) como una

serie de manejadores e interfaces diseñadas para proveer una forma para acceder a este tipo de

almacenamientos. Los servicios son puestos en la red y operan de manera cooperativa para dar

soporte a uno o más procesos de negocios. En este modelo, una aplicación se convierte en un

conjunto de servicios de usuario, negocios y datos que satisface las necesidades de los procesos de

negocios. Como los servicios están diseñados para el uso general y siguen lineamientos de interfaz,

- 28 -

pueden ser reutilizados y compartidos entre múltiples aplicaciones. La arquitectura DNA de tres

capas como se muestra en la figura 5, cuenta con servicios específicos en cada una de las capas que

se comunican entre sí mediante COM (Component Object Model).

Fig. 5 Arquitectura Tres Capas [16]

Basado en la experiencia de [16] se establece una definición de las diferentes capas utilizadas:

Capa de Presentación: es la encargada de presentar, comunicar y capturar la información desde y

hacia el usuario en un mínimo proceso. Esta capa se comunica únicamente con la capa de negocio.

Capa de Negocio: es donde residen los programas que se ejecutan, recibe las peticiones del

usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio porque es aquí

donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de

presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para

solicitar al gestor de base de datos para almacenar o recuperar datos de él.

Capa de Datos: es donde residen los datos y es la encargada de acceder a los mismos. Está

formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos,

reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

2.4.3. PATRÓN MODELO VISTA CONTROLADOR (MVC)

Para [17], el patrón MVC separa los datos de una aplicación, de manera que el Modelo (Objetos

de Negocio), la Vista (interfaz con el usuario) y el Controlador (workflow de la aplicación) se

comuniquen satisfactoriamente como muestra la figura 6. La lógica de una interfaz de usuario

cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Si se realiza un diseño

donde se mezclan los componentes de interfaz y lógica de negocio, la consecuencia se dará cuando

se cambiar la interfaz y se tendrá que modificar los componentes de negocio, generando mayor

trabajo y riesgo de error. Se trata de realizar un diseño que desacople la vista del modelo, con la

finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en

menor medida en la lógica de negocio o de datos.

- 29 -

Fig. 6 Modelo Vista Controlador [17]

2.4.4. TECNOLOGÍAS EN LA CAPA DE PRESENTACIÓN

Basados en la experiencia de [17], existen diversas tecnologías en la capa de presentación las

cuales pueden ser utilizadas en JAVA, a continuación se describe dichas tecnologías:

JavaServer Faces (JSF)

La tecnología JavaServer Faces es un marco de desarrollo de los componentes de la interfaz de

usuario, válido para todas aquellas aplicaciones web basadas en la tecnología Java.

Ajax

Es el acrónimo para Asynchronous Java Script + XML el cual significa cargar y renderizar una

página, manteniendose en la misma página, mientras los scripts y rutinas van al servidor.

Los datos usados para actualizar la página son los únicos que sufrirán los cambios ya sea

mostrando u ocultando porciones de la misma.

Facelets

Es un framework simplificado de presentación, en donde es posible diseñar de forma libre una

página web y luego asociarle los componentes JSF. Aporta mayor libertad al desarrollador y mejora

los informes de errores que presenta JSF. Permite que JSP (JavaServer Page) y JSF (JavaServer

Faces) puedan funcionar conjuntamente en una misma aplicación web. JSP procesa los elementos de

la página de arriba a abajo, mientras que JSF dicta su propio procedimiento. Facelets llena este vacío

entre JSP y JSF, siendo una tecnología centrada en crear árboles de componentes y estar relacionado

con el complejo ciclo de vida JSF.

Lenguaje de Marcado de Hipertexto Extensible (XHTML)

Es una versión más estricta y limpia de HTML, que nace con el objetivo de remplazar a HTML

ante su limitación de uso, por lo que existen abundantes herramientas basadas en XML. XHTML

extiende HTML 4.0 combinando la sintaxis de HTML, diseñado para mostrar datos.

JavaScript

Es un lenguaje de programación interpretado, es decir, no requiere de compilación ya que el

lenguaje funciona del lado del cliente, los navegadores son los encargados de interpretar estos

códigos. Tiene la ventaja de ser incorporado en cualquier página web, puede ser ejecutado sin la

necesidad de instalar otro programa para ser visualizado. Tiene como principal característica ser un

lenguaje independiente de la plataforma.

- 30 -

2.4.5. TECNOLOGÍAS EN LA CAPA DE NEGOCIO

Conforme al conocimiento de [17] existen las siguientes tecnologías a utilizar en la capa de

negocio:

Servidor de Aplicaciones

JBoss es un servidor de aplicaciones para Java. Es muy reconocido por ser de los primeros

servidores de aplicación empresarial gratuito y open source. Al estar basado en Java, puede ser

utilizado en cualquier sistema operativo que lo soporte, ofreciendo una plataforma de alto

rendimiento para aplicaciones java, aplicaciones Web y Portales.

Enterprise Java Beans (EJB)

Es una plataforma para construir aplicaciones de negocio portables, escalables, y reutilizables

utilizando el lenguaje de programación java. Permite a los desarrolladores enfocarse en la lógica del

negocio sin tener que emplear tiempo en la conformación del código de la infraestructura. Desde el

punto de vista del desarrollador es un pedazo de código java que se ejecuta en un entorno

especializado denominado contenedor EJB que proporciona un conjunto de servicios. El servicio de

persistencia es proporcionado por un framework especializado denominado proveedor de

persistencia.

Plain Old Java Object (POJO)

Son las siglas utilizadas por programadores Java para enfatizar el uso de clases simples y que no

dependen de un framework en especial.

2.4.6. TECNOLOGÍAS EN LA CAPA DE ACCESO A DATOS

Así mismo [17] recomienda la utilización de éstas tecnologías como capa de acceso a datos:

Java Persistence API (JPA)

El Java Persistence API fue desarrollado por el grupo de expertos de EJB 3.0, aunque su uso no

se limita a los componentes software EJB. También puede utilizarse directamente en aplicaciones

web y aplicaciones clientes; incluso fuera de la plataforma Java.

En su definición, se han combinado ideas y conceptos de los principales frameworks de

persistencia como Hibernate, Toplink y JDO y de las versiones anteriores de EJB. Todos estos

cuentan actualmente con una implementación JPA.

Hibernate

Hibernate es una capa de persistencia objeto/relacional y un generador de sentencias SQL.

Permite diseñar objetos persistentes que podrán incluir polimorfismo, relaciones, colecciones, y un

gran número de tipos de datos. De una manera muy rápida y optimizada se puede generar bases de

datos en cualquiera de los entornos soportados: Oracle, DB2, MySql, etc. Y lo más importante de

todo, es open source, lo que supone, entre otras cosas, que no se tiene que pagar nada por adquirirlo.

Hibernate ofrece también un lenguaje de consulta de datos llamado HQL (Hibernate Query

Language). Puede ser usado para desarrollar y distribuir aplicaciones de forma gratuita. Es utilizado

en las aplicaciones Java EE.

JBoss Seam

JBoss Seam es una nueva y poderosa aplicación para la construcción de la próxima generación de

aplicaciones Web 2.0 de la unificación y la integración de tecnologías, como Java Script asíncrono y

XML (AJAX), JavaServer Faces (JSF), Enterprise Java Beans (EJB3), Java Portlets y Business

Process Management (BPM).

- 31 -

2.4.7. ARQUITECTURA DEL SISTEMA

En base a todas las recomendaciones indicadas previamente se ha decidido implementar la

arquitectura basada en tres capas empleando el Modelo Vista Controlador con la incorporación de

JavaServer Faces JSF, Ajax, XHTML y JavaScript como tecnologías de aplicación, además se

utilizará el servidor web Apache Tomcat como tecnología de capa de negocio, así mismo se

empleará Entty Classes From Database propio de Netbeans como tecnología de Acceso a Datos,

todo esto bajo la metodología de desarrollo de software RUP (Proceso Unificado Racional), con esta

metodología se puede controlar y modificar las diferentes etapas del proceso de desarrollo mediante

versiones como se muestra en la figura 7, las fases del Proceso Unificado Racional se indican a

continuación de acorde con [18], la razón de implementar esta metodología se debe a que es

independiente entre sus fases y cubre toda el ciclo de vida del desarrollo de un proyecto de software.

Fase de Inicio: El objetivo de esta fase es desarrollar el análisis del proyecto para justificar su

puesta en marcha. Para lograrlo se realiza una descripción general del proyecto y se establece la

funcionalidad básica del software con una descripción de la arquitectura propuesta, obtención de los

objetivos, catálogo de requisitos, identificación de casos de uso.

Fase de Elaboración: Una vez finalizada la fase de inicio, se forma una arquitectura sólida para

la construcción del software, es decir, el refinamiento de los objetivos, para lo cual se establece la

base lógica de la aplicación con los casos de uso definitivos y los artefactos del sistema que lo

componen. Para esto, se efectúa la primera iteración con un prototipo funcional para la realización

de pruebas de software y la definición del modelo para la implementación de la interfaz de usuario.

Fase de Construcción: Se inicia a partir de la línea base de arquitectura que se especificó en la

fase de elaboración con el refinamiento de objetivos, y su finalidad es desarrollar o construir un

producto o sistema de información listo para la operación inicial en el entorno del usuario final.

Fase de Transición: Una vez que el proyecto entra en la fase de transición, el sistema ha

alcanzado la capacidad operativa inicial. En la fase de transición se busca implantar el producto en

su entorno de operación, garantizando que el software está listo para entregarlo a los usuarios.

Fig. 7 Fases del Proceso Unificado Racional RUP [10]

- 32 -

3. CAPÍTULO 3. ANÁLISIS

3.1. MODELADO DEL NEGOCIO

La Universidad Católica de Cuenca como todos las universidades del país se encuentran en un

proceso de mejoramiento y acreditación, la cual está siendo evaluado continuamente por el estado a

través del Consejo de Evaluación, Acreditación y Aseguramiento de la Calidad de la Educación

Superior (CEAACES), una de las áreas en la que se realizan varios procesos de mejora es la de

investigación, el área está establecida por la dirección de investigación general, este es el

departamento principal, y a su vez cada facultad posee un área de investigación la cual es formada

por diferentes docentes, miembros y delegados, por lo cual la cantidad de personas involucradas en

esta área es numerosa, por esta razón es importante crear y generar procesos que permitan al

personal de esta área incrementar su productividad a la hora de definir nuevos requerimientos o

procesos..

Para definir la importancia del sistema se debe establecer la situación actual de la Universidad

Católica de Cuenca, por lo cual en la figura 8, se observa el modelo de los procesos, este se divide en

dos factores importantes que se deben establecer al momento de realizar un sistema para la

organización, el primer factor tomado en cuenta es el contexto, en el cual se debe especificar la

razón de ser de la empresa, sus estrategias y los diferentes interesados en que se desarrolle el

sistema, el otro factor es la especificación del flujo de trabajo actual de la organización, para realizar

un análisis de los procesos que se llevan normalmente y cómo estos deben interactuar entre sí para

establecer las funciones o procesos que debe desarrollar el sistema.

Fig. 8 Modelo De Procesos

En el contexto del modelo del negocio se deben especificar la visión, misión y los diferentes

interesados en el funcionamiento del sistema web con la finalidad que les ofrezca una mejor

eficacia, eficiencia y productividad del área de investigación los cuales se visualiza en la figura 9.

- 33 -

Fig. 9 Contexto del Negocio

3.1.1. VISIÓN

La Visón de la Universidad Católica de Cuenca, tiene por prioridad construir y fomentar una

calidad de Estudios Superiores defensora de los valores éticos, profesionales y cristianos,

debidamente acredita, con optima excelencia académica para liderar proyectos ciencia e

investigación los cuales sean de vinculación con la sociedad, rescatar las culturas ancestrales y

utilizar modernas tecnologías, contribuyendo responsablemente al desarrollo de la comunidad

ecuatoriana, americana y universal.

3.1.2. MISIÓN

La Misión de la Universidad Católica de Cuenca, es inspirada en los principios cristianos y

religiosos, la generación y difusión del conocimiento científico, cultural, artístico y tecnológico, y la

formación de profesionales e investigadores con sólida preparación científica y técnica, cuyas

capacidades, valores y compromiso con la búsqueda de solución de los problemas del país con

proyectos de calidad y con recursos ecuatorianos para liderar el cambio social para el servicio a los

pueblos.

3.1.3. INTERESADOS

Los usuarios interesamos en el desarrollo del sistema informático para la gestión investigativa en

referencia al módulo de seguridades y administración son los siguientes (figura 10):

Administrador del sistema

Persona que se encargará de gestionar el sistema, controlar los accesos mediante la creación de

roles en los cuales se especificará el nivel de acceso y privilegios al sistema, también será la persona

responsable del funcionamiento óptimo del software resolviendo inconvenientes de comunicación,

servicio y soporte técnico.

Comité de Investigación

Personal designado en cada una de las Unidades Académicas, los cuales van a ser los encargados

de la revisión de proyectos.

Dirección de Investigación

Personal asignado por la Universidad Católica de Cuenca encargada del control y seguimiento de

proyectos de investigación.

Docentes

- 34 -

Son aquellos que realizan el trabajo de tutores en la Universidad Católica de Cuenca siendo los

que realizan la presentación y encargados de orientar a los estudiantes en los de proyectos de

investigación, cumpliendo el rol de investigador.

Estudiantes

Son todos los alumnos que pertenecen de la Universidad Católica de Cuenca, encargados del

desarrollo y cumplimiento de los proyectos de investigación al igual que los docentes poseerán rol

investigador.

Investigadores

Toda persona que presente, desarrolle, construya o ejecute propuestas de investigación.

Jefe del área de investigación

Es la persona encargada de establecer, controlar, gestionar y supervisar cada uno de los procesos,

análisis, objetivos y proyectos que se realizan por el área de investigación.

Rector de la Universidad Católica de Cuenca

Es la máxima autoridad de la Universidad Católica de Cuenca, al cual le interesa el bienestar y

progreso de las diferentes áreas y Unidades Académicas de la Universidad, para el mejoramiento y

reconocimiento de la institución a nivel local, nacional y mundial.

Fig. 10 Análisis de Interesados

3.2. IDENTIFICACIÓN DE REQUERIMIENTOS

El departamento de Investigación de la Universidad Católica de Cuenca ha definido la estructura,

objetivos y reglamentos del área de investigación, así mismo las personas y sus respectivas

funciones de cada comité relacionado a la gestión de los proyectos y los diferentes procesos que se

deben realizar para llevar a cabo un proceso correcto de la formación investigativa.

Para la simbología, entendimiento e identificación de los requerimientos es importante la

implantación de diagramas UML que permiten realizar el proceso de análisis y diseño de manera

organizada, estandarizada y clara, por lo cual es importante identificar los elementos que se

implementan en UML, en la figura 11, se observa la representación gráfica de cada uno de ellos que

se detalla a continuación.

- 35 -

Asociación: Es una relación la cual indica que dos clases se relacionan entre sí para poder realizar

algún proceso, con la característica que sin el uno no depende del otro para poder existir, esta

relación es representada por una línea que une los dos objetos que interactúan entre sí.

Agregación: Es una relación similar a la asociación, en la cual los dos objetos se relacionan y

comparten sus métodos y atributos pero aquella dependencia que hay entre los dos es débil, es decir

si el uno se destruye el otro puede seguir existiendo, esta relación es representada con una línea con

un rombo color blanco en el extremo de la clase principal.

Composición: de igual forma que la agregación, existe una relación de dependencia, con la

diferencias que esta es una dependencia fuerte, en la que la clase secundaria depende del ciclo de

vida de la clase principal, esta relación es representada con una línea y rombo de color negro en el

extremo de la clase principal.

Dependencia: Esta relación indica que el objeto secundario dependerá de un objeto principal, esta

relación es representada por una flecha punteada.

Generalización: En este caso la clase secundaria hereda los atributos y métodos de la clase

principal, esta relación es representada por una flecha con la punta de color blanco.

Fig. 11 Simbología UML [3]

3.2.1. REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales se rigen directamente al área de software, mientras la parte de

hardware que pueda causar interrupción en alguno de los requerimientos no funcionales deberá ser

tomada en cuenta por el área técnica encargada del control del servidor en el que se aloje el sitio

web, a continuación se especifican los requerimientos no funcionales solicitados por parte del área

de investigación en la figura 12, se observará los beneficios que el sistema web brindará.

Fig. 12 Requerimientos No Funcionales

- 36 -

DISPONIBILIDAD

Fig. 13 Disponibilidad

TABLA I REQUERIMIENTOS DE DISPONIBILIDAD

ESCALABILIDAD

Fig. 14 Escalabilidad

TABLA II REQUERIMIENTOS DE ESCALABILIDAD

REQ102 - Proveer Escalabilidad

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

Se debe ofrecer un sistema con los mecanismos necesarios para soportar la escalabilidad, es

decir la habilidad para reaccionar y adaptarse sin perder calidad en el sistema, de igual forma en

manejar el crecimiento de trabajo de manera fluida.

REQ1021 - Adaptación de Nuevos Módulos

Estado: Aprobado Prioridad: Media Dificultad: Media

REQ101 - Proveer Disponibilidad

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema informático debe ser accesible desde su entorno web, y estar disponible 24 horas 7

días a la semana los 365 días del año.

REQ1011 - Entorno Web

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

- 37 -

Fase: 1.0 Versión: 1.0

Dar facilidad para la adaptabilidad e implementación de nuevos módulos, características o

funciones.

REQ1022 - Concurrencia

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

Garantizar que el sistema soporte la concurrencia de usuarios, evitando que colapse cuando

haya mayor uso del sistema en que las transacciones puedan ser realizadas simultáneamente.

SEGURIDAD

Fig. 15 Seguridad

TABLA III REQUERIMIENTOS DE SEGURIDAD

REQ103 - Procesamiento de Información Seguro

Estado: Obligatorio Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe garantizar que el procesamiento de la información se realiza de manera segura,

brindando la integridad de los datos.

REQ1031 - Almacenamiento Seguro

Estado: Obligatorio Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe garantizar la integridad y confiabilidad de la información la cual debe

almacenarse correctamente e identificar que usuario realiza cada transacción, se debe garantizar

que toda transacción tenga un responsable para poder realizar un proceso de auditoría 100%

confiable.

REQ1032 - Transacciones Seguras

Estado: Obligatorio Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

Toda transacción debe ser almacenada de manera segura, en caso de que una transacción no se

- 38 -

guarde se debe indicar la razón para que el usuario tenga conocimiento del error y realizar

nuevamente el proceso.

3.2.2. REQUERIMIENTOS FUNCIONALES

En base al análisis, se establecieron los requerimientos funcionales que se observa en la figura

16.

Fig. 16 Requerimientos Funcionales

ADMINISTRACIÓN DEL SISTEMA

Administración De Permisos

Fig. 17 Administración de Permisos

TABLA IV REQUERIMIENTOS DE ADMINISTRACIÓN DE PERMISOS

REQ001 - Administración de Permisos

Estado: Obligatorio Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe facilitarnos gestionar los diferentes accesos al sistema.

REQ0011 - Crear Permisos

Estado: Aprobado Prioridad: Media Dificultad: Media

- 39 -

Fase: 1.0 Versión: 1.0

El sistema debe permitir crear nuevos permisos a los diferentes módulos del sistema.

REQ0012 - Eliminar Permisos

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir eliminar permisos existentes.

REQ0013 - Modificación de Permisos

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de los permisos creados para el sistema.

Administración De Usuarios

Fig. 18 Administración de Usuarios

TABLA V REQUERIMIENTOS DE ADMINISTRACIÓN DE USUARIOS

REQ002 - Administración de Usuarios

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

EL sistema debe permitir gestionar los diferentes usuarios del sistema.

REQ0021 - Crear Usuarios

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso y registro de nuevos usuarios.

REQ0022 - Eliminar Usuarios

- 40 -

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir eliminar usuarios ingresados en el sistema.

REQ0023 - Modificación de Usuarios

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de los usuarios.

REQ0024 - Control del Acceso al Sistema

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe controlar los accesos al sistema a través interfaces de validación de usuarios en

donde se asignará el rol respectivo, cada rol debe tener especificado a que módulos o transacciones

tiene acceso el usuario.

Administración De Roles

Fig. 19 Administración de Roles

TABLA VI REQUERIMIENTOS DE ADMINISTRACIÓN DE ROLES

REQ003 - Administración de Roles

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar los diferentes roles del sistema los cuales serán asignados a

los diferentes tipos de usuarios.

REQ0031 - Crear Roles

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

- 41 -

El sistema debe permitir la creación de nuevos roles.

REQ0032 - Eliminar Roles

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir eliminar roles, únicamente si el rol a eliminar no haya sido asignado a

un usuario activo.

REQ0033 - Modificación de Roles

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de los roles, ya sea en su descripción u otro dato que

no altere al funcionamiento del sistema.

Administración De Menús

Fig. 20 Administración de Menús

TABLA VII REQUERIMIENTOS DE ADMINISTRACIÓN DE MENÚS

REQ004 - Administración de Menús

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar los diferentes menús del sistema, los cuales darán acceso a

las transacciones o módulos existentes en el sistema.

REQ0041 - Crear Menús

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la creación de nuevos menús al sistema.

REQ0042 - Eliminar Menús

Estado: Aprobado Prioridad: Media Dificultad: Media

- 42 -

Fase: 1.0 Versión: 1.0

El sistema debe permitir eliminar menús.

REQ0043 - Modificación de Menús

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de menús existentes del sistema.

Administración De Submenús

Fig. 21 Administración de Submenús

TABLA VIII REQUERIMIENTOS DE ADMINISTRACIÓN DE SUBMENÚS

REQ005 - Administración de Submenús

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar los diferentes submenús del sistema que serán asignados a un

menú principal los cuales serán creados como se menciona en la TABLA VII.

REQ0051 - Crear Submenús

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la creación de nuevos submenús al sistema asociado a un menú padre o

principal.

REQ0052 - Eliminar Submenús

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir eliminar los submenús.

REQ0053 - Modificación de Submenús

Estado: Aprobado Prioridad: Media Dificultad: Media

- 43 -

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de submenús del sistema.

GESTIÓN DE PROYECTOS

Fig. 22 Gestión de Proyectos

TABLA IX REQUERIMIENTOS DE GESTIÓN DE PROYECTOS

REQ006 - Gestión de Proyectos

Estado: Obligatorio Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir a los investigadores poder realizar la respectiva gestión de

proyectos que se presentan en las diferentes convocatorias.

REQ0061 -Ingreso de Proyectos

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

En primera instancia un miembro del grupo de investigadores debe de ingresar los datos

básicos de un proyecto especificando su respectiva convocatoria, solicitud, tipo y nivel de

investigación con la finalidad que el proyecto creado sea accesible en las demás fases de la

gestión de proyectos de investigación.

REQ0062 - Especificación de Objetivos

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir a los investigadores establecer los respectivos objetivos

Específicos, General y Fin, en todos se deberá ingresar los objetivos de Jerarquía, Línea,

Definición, Fuentes y Supuestos.

REQ0063 - Ingreso de Integrantes

- 44 -

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe dar la facilidad al investigador de especificar cuáles serán los ejecutores

del proyecto, los cuales deben estar registrados en el sistema para poder pertenecer como

integrantes.

REQ0064 - Aprobación de Proyectos

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

Cuando un proyecto cumple el 100% o cierto porcentaje aceptable con los requerimientos

establecidos, el departamento de investigación realiza la respectiva aprobación del proyecto,

dando inicio a la puesta en ejecución del mismo.

REQ0066 - Ingreso de Ajustes

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

Cuando un proyecto no cumple el 100% con los requerimientos establecidos, se solicita

al director del proyecto especificar los ajustes necesarios los cuales será ingresado por el

personal del departamento de investigación.

GESTIÓN DE CONVOCATORIAS

Gestión de Cronogramas

Fig. 23 Gestión de Cronogramas

TABLA X REQUERIMIENTOS DE GESTIÓN DE CRONOGRAMAS

REQ007 - Gestión de Cronogramas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar los diferentes cronogramas para las convocatorias y asignar

las actividades correspondientes, los cronogramas deben ser gestionados por cada Unidad

Académica, y ellos establecen sus propias fechas para cada convocatoria.

REQ0071 - Crear Cronogramas

- 45 -

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de nuevos cronogramas.

REQ0072 - Eliminar Cronogramas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de cronogramas.

REQ0073 - Modificación de Cronogramas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de los cronogramas.

Gestión de Convocatorias

Fig. 24 Gestión de Convocatorias

TABLA XI REQUERIMIENTOS DE GESTIÓN DE CONVOCATORIAS

REQ008 - Gestión de Convocatorias

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar las diferentes convocatorias, estas convocatorias deben ser

difundidas automáticamente en el sitio web del área de investigación.

REQ0081 - Crear Convocatorias

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de convocatorias.

- 46 -

REQ0082 - Eliminar Convocatorias

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de convocatorias.

REQ0083 - Modificación de Convocatorias

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de las convocatorias.

Gestión de Solicitudes

Fig. 25 Gestión de Solicitudes

TABLA XII REQUERIMIENTOS DE GESTIÓN DE SOLICITUDES

REQ009 - Gestión de Solicitudes

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar las diferentes solicitudes, con su respectiva especificación de

parámetros grupales y la asignación de formatos.

REQ0091 - Crear Solicitudes

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de nuevas solicitudes.

REQ0092 - Eliminar Solicitudes

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de solicitudes.

- 47 -

REQ0093 - Modificación de Solicitudes

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de las solicitudes.

GESTIÓN UNIVERSITARIA

Administración de Carreras

Fig. 26 Administración de Carreras

TABLA XIII REQUERIMIENTOS DE ADMINISTRACIÓN DE CARRERAS

REQ010 - Administración de Carreras

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar las diferentes carreras que en el sistema están relacionadas

con las facultades que componen a la universidad que están asociadas a las escuelas.

REQ0101 - Crear Carreras

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de carreras.

REQ0102 - Eliminar Carreras

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de carreras.

REQ0103 - Modificación de Carreras

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de las carreras.

- 48 -

Administración de Escuelas

Fig. 27 Administración de Escuelas

TABLA XIV REQUERIMIENTOS DE ADMINISTRACIÓN DE ESCUELAS

REQ011 - Administración de Escuelas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar las diferentes escuelas que componen a la Universidad, las

escuelas están asociadas con las Unidades Académicas que conforman la Universidad Católica de

Cuenca.

REQ0111 - Crear Escuelas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de escuelas.

REQ0112 - Eliminar Escuelas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de escuelas.

REQ0113 - Modificación de Escuelas

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de las escuelas.

Gestión de Niveles de Investigación

- 49 -

Fig. 28 Gestión de Niveles de Investigación

TABLA XV REQUERIMIENTOS DE GESTIÓN DE NIVELES DE INVESTIGACIÓN

REQ012 - Gestión de Niveles de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir gestionar los diferentes Niveles de investigación con la finalidad que

puedan ser utilizadas en la creación de nuevos proyectos que se desarrollarán en cada una de las

Unidades Académicas que conforma la Universidad Católica de Cuenca.

REQ0121 - Crear Niveles de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de Niveles de Investigación.

REQ0122 - Eliminar Niveles de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de Niveles de Investigación.

REQ0123 - Modificación Niveles de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización de Niveles de Investigación.

Gestión de Tipos de Investigación

- 50 -

Fig. 29 Gestión de Tipos de Investigación

TABLA XVI REQUERIMIENTOS DE GESTIÓN DE TIPOS DE INVESTIGACIÓN

REQ013 - Gestión de Tipos de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

EL sistema debe permitir gestionar los diferentes Tipos de investigación con la finalidad que

puedan ser utilizadas en la creación de nuevos proyectos que se desarrollarán en cada una de las

unidades académicas.

REQ0131 - Crear Tipos de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir el ingreso de Tipos de Investigación.

REQ0132 - Eliminar Tipos de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir realizar la eliminación de Tipos de Investigación.

REQ0133 - Modificación Tipos de Investigación

Estado: Aprobado Prioridad: Media Dificultad: Media

Fase: 1.0 Versión: 1.0

El sistema debe permitir la actualización Tipos de Investigación.

3.2.3. COMPORTAMIENTO DEL SISTEMA

3.2.4. PERSPECTIVA GENERAL DE LA APLICACIÓN

Se espera una aplicación confiable, cien por ciento segura y amigable, que sea capaz de dar

cumplimiento, satisfacción y soporte a todas las necesidades de los usuarios, una vez se realice un

análisis inicial de los requerimientos es importante establecer el comportamiento que tendrá el

sistema al ser implementado por el usuario para realizar cada una de los requerimientos establecidos,

dicho comportamiento se realiza a través de diagramas de casos de uso, lo cual nos indica

claramente el flujo de trabajo en cada uno de los procesos de gestión que realizara el sistema.

- 51 -

3.2.5. DEFINIR EL ALCANCE

En primera instancia el sistema informático se implantará en la Unidad Académica de Ingeniería

de Sistema, Eléctrica y Electrónica de la Universidad Católica de Cuenca, al alcanzar una

aceptación, rendimiento y funcionabilidad total de un porcentaje considerable de resultados positivos

tras la implantación e implementación del sistema y con la aprobación de la dirección de

investigación se realizará la implantación del sistema para todas las Unidades Académicas que

forman parte de la institución educativa.

3.2.6. CONTEXTO

El sistema según las necesidades, planificación y objetivos de la dirección de investigación de la

Universidad Católica de Cuenca se acoplará a otros sistemas para obtener información que ayuden al

proceso del gestión de proyectos, pero de manera inicial el sistema será independiente y no necesita

de ningún otro sistema para su correcto funcionamiento.

3.2.7. CASOS DE USO

Administración del Sistema, en este proceso el usuario que se desempeñará como administrador

del sistema debe gestionar adecuadamente los accesos y permisos que serán asignados a cada rol, y a

su vez asignar a los usuarios uno o varios roles en la figura 30, se observa la comunicación que tiene

el usuario con cada proceso de la administración del sistema.

Nombre del Caso de Uso: Gestionar roles.

Escenario: El usuario realiza la creación de roles indicando el nombre y una breve descripción

del rol, la actualización, activación, desactivación y eliminación se produce sobre roles ya existentes.

Fig. 30 Caso de Uso - Administración del Sistema

- 52 -

El usuario administrador del sistema será el encargado de asignar los respectivos módulos o

transacciones a las cuáles podrá acceder el usuario a quien se asigne los diferentes roles que se

crearán.

Actores Involucrados: Usuario, Roles.

Nombre del Caso de Uso: Gestionar Usuarios.

Escenario: Un usuario realiza el ingreso o actualización de los usuarios que realizan tareas de

gestión sobre el sistema, por otro lado los usuarios que no intervienen en la gestión pero interactúan

con las opciones del sistema se pueden registrar y crear un usuario para realizar los procesos de

investigación que le competan.

Actores Involucrados: Usuario.

Nombre del Caso de Uso: Asignar Roles.

Escenario: Permitir al usuario administrador realizar la asignación de los usuarios a los diferentes

roles, donde los roles tienen asignados los accesos al sistema.

Actores Involucrados: Usuario, roles.

Nombre del Caso de Uso: Gestionar Permisos.

Escenario: Permite realizar la asignación de acceso a las diferentes opciones del sistema cada

opción se le conoce con en el nombre menú y submenú que maneja el sistema, en cada permiso que

se crea se especifica las operaciones que podrán realizar cada usuario, entre las operaciones que se

controlan están: Creación, Modificación, Activar o Desactivar, Ver y Eliminar.

Actores Involucrados: Menú, sub menú, permisos, usuario.

El sistema debe ser capaz de soportar toda la gestión de datos correspondientes a la Universidad,

como son las carreras o escuelas, es decir, las Unidades Académicas y Facultades existentes y por

existir en la Universidad Católica de Cuenca respectivamente y cada uno de los Tipos y Niveles de

Investigación, este proceso es sencillo y básico ya que la información que debe gestionar se limita a

nombre y breves descripciones que permitan identificarlos de manera rápida. La gestión de las

carreras y escuelas permite realizar la creación y actualización de la información ingresada, en la

figura 31, donde se observan los procesos que intervienen en este módulo.

Fig. 31 Caso de Uso - Administración de Escuelas y Carreras

Nombre del Caso de Uso: Gestionar Escuelas.

Escenario: las escuelas hacen referencia a las unidades académicas que conforman la universidad

Católica de Cuenca, en este proceso el usuario puede crear y realizar la gestión de las diferentes

escuelas que forman parte de la universidad.

Actores Involucrados: Escuelas, usuarios.

Nombre del Caso de Uso: Gestionar Carreras.

- 53 -

Escenario: las carreras hacen referencia a las facultades que forman parte de cada Unidad

Académica, a través de este proceso el usuario puede crear y gestionar las diferentes carreras que

pertenecerán a cada escuela.

Actores Involucrados: Carreras, usuario, escuela.

La gestión de Tipos de investigación son establecidas por la dirección de investigación, los cuales

serán especificadas en la gestión de proyectos, los tipos de investigación los cuales son ingresadas al

sistema por el administrador deben englobar de manera general los tipos de investigación existentes

en todas las unidades académicas, en la figura 32, se muestra el funcionamiento de estos procesos.

Fig. 32 Caso de Uso - Gestión Tipos de Investigación

Nombre del Caso de Uso: Gestionar tipos de investigación.

Escenario: permitir a la dirección de investigación conjuntamente con el administrador del

sistema crear y administrar los tipos de investigación que harán parte en los proyectos.

Actores Involucrados: Dirección de investigación, Administrador del Sistema, Proyectos.

La gestión de niveles de investigación son establecidas por la Dirección de Investigación, las

cuales serán especificadas en la gestión de proyectos, los niveles de investigación los cuales se

ingresan al sistema por el administrador deben especificar el nivel a cual está orientado el proyecto,

en la figura 33, se muestra el funcionamiento de estos procesos.

Fig. 33 Caso de Uso - Gestión Niveles de Investigación

Nombre del Caso de Uso: Gestionar niveles de investigación.

Escenario: permitir a la dirección de investigación conjuntamente con el administrador del

sistema crear y administrar los niveles de investigación que será especificado en la gestión de

proyectos.

Actores Involucrados: Dirección de investigación, Administrador del Sistema, Proyectos.

- 54 -

Fig. 34 Caso de Uso - Gestión Proyectos

Nombre del Caso de Uso: Gestionar Proyectos de Investigación.

Escenario: permitir a los usuarios o investigadores ingresar el proyecto, asignar integrantes y

especificar los objetivos. De igual manera permitir al Comité de Investigación aprobar o detallar los

ajustes a proyectos que cumplen o no con lo estipulado.

Actores Involucrados: Comité de investigación, Usuarios, Proyectos.

Fig. 35 Caso de Uso - Gestión de Reportería

- 55 -

Nombre del Caso de Uso: Gestionar Reportería.

Escenario: permitir a los Usuarios o Investigadores, Comité de Investigación y al Administrador

del sistema a generar y obtener información del reporte.

Actores Involucrados: Comité de investigación, Usuarios, Administrador del Sistema.

3.3. ANÁLISIS DE LA SOLUCIÓN

La fase en la que se establecen los requisitos del sistema es las más importante, fundamental y

esencial, ya que en base a ellos se establece la lógica del negocio que el sistema debe realizar, de

igual manera los diagramas de casos de uso permiten establecer las clases que intervendrán en el

sistema.

3.3.1. MODELADO DE CLASES

Para identificar le relación que hay entre las entidades y establecer un diagrama de base de datos

es importante realizar un diagrama de clases, el cual permite saber la comunicación entre cada

proceso y cada uno de los involucrados, para este diagrama se establecieron 7 módulos, en la figura

36 se visualiza el proceso entre ellos.

Fig. 36 Modelo de Clases

El módulo de Administración del sistema es uno de los más importantes, ya que ésta se

convertirá en la base fundamental del sistema, no solo en éste si no en cualquier tipo de sistema web,

aplicación o plataforma informática que manejen niveles de accesos a la información, en este

módulo se encuentra involucrados diferentes entidades como se indica en la figura 37, cuando se

habla de permisos determina los acceso al sistema, los menús y submenús son aquellos que redirigen

a los mantenimientos existentes, por último es fundamental definir una entidad de control, esta

entidad nos permite llevar una auditoria de todo lo que realiza un usuario.

- 56 -

Fig. 37 Módulo de Administración del Sistema

Los permisos son asignados a un rol, y un rol asignado a un usuario, con esto el usuario obtiene

el acceso y permisos al sistema que pueden ser: creación, actualización, eliminación, activación,

desactivación de registros y el permiso de impresión, estos son los principales permisos para el

control adecuado de las diferentes operaciones en el sistema.

El módulo de gestión universitaria es aquella que gestiona las entidades que son solo de carácter

informativo, con estas se puede identificar, la relación o dependencia que existe entre los proyectos y

cada tipo y nivel de investigación, de igual forma conocer a que carreras y escuela pertenece un

usuario, en la figura 38, se visualiza y especifica el comportamiento del módulo.

Fig. 38 Módulo de Gestión Universitaria

Las convocatorias es la base fundamental del sistema, ya que en ella se definen los formatos,

cronogramas, actividades, solicitudes, tipo de proyecto, es decir el sistema permite la administración

de proyectos de investigación o de cualquier otro tipo de proyecto, en la figura 39, se observa la

comunicación entre las entidades descritas, la estructura de una convocatoria permite reutilizarlas, es

importante indicar que las convocatorias ingresadas por cada escuela o facultad.

Los formatos que están vinculados a una base de convocatoria son archivos que se suben al

sistema.

Las solicitudes son requerimientos que se hacen a un proyecto, cuando se realiza una solicitud los

integrantes del proyecto, deben cumplir con aquellos requerimientos y subir un documento en

respuesta a la solicitud, que pasan a ser anexos del proyecto. Cuando una solicitud tiene que ser

- 57 -

evaluada se deben establecer parámetros de revisión que determinan bajo qué características o

criterios se va a calificar los proyectos, los parámetros de revisión se dividen en dos, el parámetro

grupo y el parámetro detalle pero se identifican bajo una clase principal llamada parámetros de

revisión, estos parámetros son implementados para realizar la calificacion de un proyecto, en base a

los parámetros se generan formularios de calificación, los cuales permiten definir si un proyecto es

aprobado, rechazado o si necesita de ajustes, cada revisión debe generar un resultado con la fnalidad

de llevar un control para conocer que cambios se realizó sobre la solicitud, en la figura 40 se observa

la comunicación de todas las entidades en este módulo.

Fig. 39 Módulo de Convocatorias

El modulo gestión de proyecto controla el ingreso y administración, los cuales se componen de

datos informativos que permitirán realizar los reportes necesario para un control y seguimiento de

los proyectos, los datos básicos para estos proyectos son los datos de los integrantes, los objetivos y

los diferentes documentos que apoyan a la presentación y desarrollo del proyecto en la figura 41, se

observa el flujo de trabajo para gestionar correctamente este módulo.

- 58 -

Fig. 40 Módulo Gestión de Solicitudes

Fig. 41 Módulo de Gestión de Proyectos

3.3.2. MODELADO DE BASE DE DATOS

Al analizar rigurosamente los casos de uso y diagrama de clases los cuales son importantes para

el desarrollo de un sistema, ya que en ellos se definen las necesidades, lógica del negocio y

determinan qué información es vital para la Universidad Católica de Cuenca, guiados en este análisis

que observa la figura 42, la cual indica las tablas que fueron creadas, analizando los diferentes

actores que se involucran en los casos de uso y en el diagrama de clases.

- 59 -

3.3.3. DICCIONARIO DE DATOS

En la tabla 17, encontramos una descripción de las entidades que se establecieron en el diagrama

de base de datos, especificando el nombre, tipo de entidad, clave primaria y el número de atributos,

en el tipo de entidad existen dos tipos independiente el cual indica que la entidad no depende de otra

para existir y dependiente dependen de otras entidad para su funcionamiento y existencia.

TABLA XVII ENTIDADES

Nombre de Entidad Tipo de entidad Clave Primaria # Atributos

actividad independiente actid 5

actividad_cronograma dependiente actid, croid 5

ajuste independiente ajuid 7

archivo independiente arcid 5

base_solicitud dependiente solid, basid 2

baseconvocatoria independiente Basid 5

bien independiente Bieid 8

calificación independiente Calid 6

calificaciondetalle dependiente Parid, pardetid,calid 6

Cargo independiente Carid 3

carrera independiente carid 6

certificado independiente cerid 6

certificadodetalle dependiente cerid, serid, bieid 6

control dependiente ctrid, usuid 11

convocatoria independiente conid 10

convocatoria_carrera dependiente conid, carid 2

cronograma independiente croid 7

documento independiente docid 9

escuela independiente escid 5

formato independiente frtid 6

integrante independiente intid, proid 8

linea_base dependiente basid, linid 2

lineainvestigacion independiente linid 5

menu independiente menuid 7

nivelinvestigacion independiente nivid 5

objetivo independiente objid 9

parametro independiente parid 8

parametro_parametrodetalle dependiente parid, pardetid 5

parametrodetalle independiente pardetid 6

permiso independiente permid 13

persona independiente perid 10

Personal independiente persid 3

proyecto dependiente Proid, conid, tipinvid,

nivid,solid 15

revisionpendiente independiente revpenid 3

rol independiente rolid 5

rolintegrante Dependiente rolid, intid 6

solicitud independiente solid 6

solicitud_formato dependiente solid, frtid 2

solicitud_parametro dependiente solid, parid 2

sublinea independiente Subid, linid 6

sublinea_carrera dependiente subid, carid 2

submenu independiente smenuid 7

tipobien independiente tipid 5

tipodocumento independiente tipid 5

- 60 -

En la tabla 18, se especifica cada uno de los atributos existentes en cada entidad.

TABLA XVIII LISTADO DE ATRIBUTOS

Nombre Nombre Tabla Tipo de

Dato Descripción

actdescripcion actividad Text Descripción de una actividad.

acteliminado actividad Char (20) Indica la eliminación lógica de una actividad, valores permitidos “Si” y “No”.

actestado actividad Char (20) Indica el estado de una actividad, valores permitidos “Activo” e “Inactivo”

actid actividad Integer Código secuencial de una actividad.

actnombre actividad Char Nombre de la actividad.

acfechafin actividad_cronograma Date Fecha de fin de una actividad.

acfechainicio actividad_cronograma Date Fecha de inicio de una actividad.

croid actividad_cronograma Integer Especifica la relación con un Cronograma

actid actividad_cronograma Integer Indica las actividades asignadas a un cronograma.

croid actividad_cronograma Integer Indicas las actividades que pertenecen a un cronograma.

solid actividad_cronograma Integer Indica la actividad que corresponde a la solicitud en un cronograma de cada convocatoria.

ajudescripcion ajuste Text Descripción de los ajustes solicitados.

ajueliminado ajuste Char (20) Indica la eliminación lógica de un ajuste, valores permitidos “Si” y “No”.

ajuestado ajuste Char (20) Indica el estado de un ajuste, valores

permitidos “Activo” e “Inactivo”

ajufecha ajuste Date Fecha de solicitud del ajuste

ajuid ajuste Integer Código secuencial de un ajuste.

ajutitulo ajuste Char (255) Nombre del ajuste solicitado.

proid ajuste Integer Especifica la relación con un proyecto

calid ajuste Integer Indican las calificaciones que generaron el ajuste.

proid ajuste Integer Indica los ajustes solicitados a un proyecto.

arceliminado archivo Char (20) Indica la eliminación lógica de un archivo, valores permitidos “Si” y “No”.

arcestado archivo Char (20) Indica el estado de un archivo, valores permitidos “Activo” e “Inactivo”

arcextension archivo Char (20) Extensión del archivo que se sube al

servidor, ejemplo Pdf, Word, entre otros.

arcid archivo Integer Código secuencial de un archivo.

arcruta archivo Text Ruta en la que se guarda un archivo.

basid base_solicitud Integer Indica las solicitudes que perteneces una

base de convocatoria.

solid base_solicitud Integer Indica las solicitudes que son asignadas a una base de convocatoria.

basdescripcion baseconvocatoria Text Descripción de una base de convocatoria

baseliminado baseconvocatoria Char (20) Indica la eliminación lógica una base de convocatoria, valores permitidos “Si” y “No”.

basestado baseconvocatoria Char (20) Indica el estado de una base de convocatoria, valores permitidos “Activo” e “Inactivo”

basid baseconvocatoria Integer Código secuencial de una base de convocatoria.

tipoinvestigacion independiente tipinvid 5

tipoproyecto independiente tipid 5

usuario independiente usuid, perid 7

usuario_carrera dependiente carid, usuid 2

usuario_rol dependiente usuid, rolid 2

- 61 -

basnombre baseconvocatoria Char (255) Nombre de una base de convocatoria.

biecantidad bien Integer Cantidad de bienes disponibles.

biedescripcion bien Text Descripción de un bien.

bieeliminado bien Char (20) Indica la eliminación lógica un bien, valores permitidos “Si” y “No”.

bieestado bien Char (20) Indica el estado de un bien, valores permitidos “Activo” e “Inactivo”

biefechacreacion bien Date Indica la fecha de creación del bien.

bieid bien Integer Código secuencial de un bien.

bienombre bien Char (255) Nombre del bien.

tipid bien Integer Indica el tipo de bien al que pertenece un bien.

calfecha calificacion Date Fecha de una calificación.

calid calificacion Integer Código secuencial de una calificación.

calobservacion calificacion Text Observación de una calificación.

revpenid calificacion Integer Indica las revisiones que han sido calificadas.

solid calificacion Integer Indica las solicitudes que han sido calificadas.

usuid calificacion Integer Usuario que realiza una calificación.

caldetobservacion calificaciondetalle Text Observación de una calificación realizada.

caldetvalorcualitativo calificaciondetalle Char (20) Valor que obtiene cada calificación, esta calificación es cualitativa.

caldetvalorcuantitativo calificaciondetalle Char (20) Valor que obtiene cada calificación, esta calificación es cuantitativo.

calid calificaciondetalle Integer Indica el código de la cabecera de cada

calificación.

pardetid calificaciondetalle Integer Código del parámetro de cual se realiza una calificación.

parid calificaciondetalle Integer Indica el parámetro que es calificado.

cardescripcion Cargo Text Descripción que recibe un cargo.

carid Cargo Integer Código secuencial de un Cargo.

carnombre Cargo Char (255) Nombre del cargo.

cardescripcion carrera Text Descripción que recibe una facultada

“carrera”.

careliminado carrera Char (20) Indica la eliminación lógica una carrera, valores permitidos “Si” y “No”.

carestado carrera Char (20) Indica el estado de una carrera, valores permitidos “Activo” e “Inactivo”

carid carrera Integer Código secuencial de una carrera.

carnombre carrera Char (255) Nombre de la carrera.

escid carrera Integer Indica la carrera a la que pertenece una carrera.

cerid certificado Integer Código secuencial de un certificado.

cerdescripcion certificado Text Descripción de un certificado.

cereliminado certificado Char (20) Indica la eliminación lógica de un certificado, valores permitidos “Si” y “No”.

cerestado certificado Char (20) Indica el estado de un certificado, valores permitidos “Activo” e “Inactivo”

cerfechaasignacion certificado Date Fecha en la asignación de un bien.

persid certificado Integer Indica el personal que tiene asignado uno o varios bienes.

bieid certificadodetalle Integer Indica los bienes que han sido asignados o devueltos.

cerid certificadodetalle Integer Indica el certificado al que pertenece el detalle.

cerdetdescripcion certificadodetalle Text Descripción del detalle de un certificado.

cerdeteliminado certificadodetalle Char (20) Indica la eliminación lógica del detalle de un certificado, valores permitidos “Si” y “No”.

- 62 -

cerdetestado certificadodetalle Char (20)

Indica el estado del detalle de un

certificado, valores permitidos “Activo” e “Inactivo”

serid certificadodetalle Char (500) Bienes asignados al personal.

ctrcodigomovimiento control Integer Código de la tabla número 1 en la que se genera una transacción.

ctrcodigomovimiento2 control Integer Código de la tabla número 2 en la que se genera una transacción.

ctrcodigomovimientocadena

control Char (20) Código de la tabla número 1 en la que se genera una transacción.

ctrcodigomovimientocadena2

control Char (20) Código de la tabla número 2 en la que se genera una transacción.

ctrfecha control Date Fecha en la que se realiza una transacción.

ctrhora control Time Hora en la que se realiza una transacción.

ctrid control Serial Código secuencial del control.

ctrtabla control Char (255) Nombre de la tabla 1 afectada.

ctrtabla2 control Char (255) Nombre de la tabla 2, en la que se ejecuta una transacción.

ctrtipotransaccion control Char (20)

Tipo de transacción que se ejecuta, valores

permitidos: Crear, Eliminar Lógicamente, Modificar, Eliminar Físicamente.

usuid control Integer Usuario que realiza una transacción.

basid convocatoria Integer Código secuencial de una convocatoria.

condescripcion convocatoria Text Descripción de una convocatoria.

coneliminado convocatoria Char (20) Indica la eliminación lógica de una convocatoria, valores permitidos “Si” y “No”.

conestado convocatoria Char (20) Indica el estado de una convocatoria, valores permitidos “Activo” e “Inactivo”

confechacierre convocatoria Date Fecha de cierre de una convocatoria.

confechacreacion convocatoria Date Fecha de inicio de apertura de una convocatoria.

conid convocatoria Integer Código secuencial de una convocatoria.

connombre convocatoria Char (255) Nombre de la convocatoria.

croid convocatoria Integer Código secuencial de una convocatoria.

tipid convocatoria Integer Indica el tipo de proyecto al que pertenece una convocatoria.

carid convocatoria_carrera Integer Indicas las carreras asignadas a cada convocatoria.

conid convocatoria_carrera Integer Indica las convocatorias que pertenecen a una carrera.

croeliminado cronograma Char (20) Indica la eliminación lógica de un cronograma, valores permitidos “Si” y “No”.

croestado cronograma Char (20) Indica el estado de un cronograma, valores permitidos “Activo” e “Inactivo”

crofechafin cronograma Date Fecha de terminación de un cronograma.

crofechainicio cronograma Date Fecha de inicio de un cronograma.

croid cronograma Integer Código secuencial de un cronograma.

cronombre cronograma Char (255) Especifica el nombre del cronograma

crodescripcion cronograma Text Especifica la descripción del cronograma

arcid documento Integer Id del archivo al que corresponde un documento.

docdescripcion documento Text Descripción de un documento.

doceliminado documento Char (20) Indica la eliminación lógica de un documento, valores permitidos “Si” y “No”.

docestado documento Char (20) Indica el estado de un documento, valores permitidos “Activo” e “Inactivo”

docid documento Integer Código secuencial de un documento.

docnombre documento Char (255) Nombre de un documento.

proid documento Integer Indica los documentos de un proyecto.

solid documento Integer Indica a que solicitud pertenece cada

- 63 -

documento.

tipid documento Integer Indica el tipo de documento.

escdescripcion escuela Text Descripción de un documento.

esceliminado escuela Char (20) Indica la eliminación lógica de una escuela, valores permitidos “Si” y “No”.

escestado escuela Char (20) Indica el estado de una escuela, valores permitidos “Activo” e “Inactivo”

escid escuela Integer Código secuencial de una escuela.

escnombre escuela Char (255) Nombre de una unidad académica

“escuela”.

arcid formato Integer Id del archivo al que corresponde un formato.

frtdescripcion formato Text Descripción de un formato.

frteliminado formato Char (20) Indica la eliminación lógica de un formato, valores permitidos “Si” y “No”.

frtestado formato Char (20) Indica el estado de un formato.

frtid formato Integer Código secuencial de un formato

frtnombre formato Char (255) Nombre de un formato.

inteliminado integrante Char (20) Indica la eliminación lógica de un integrante, valores permitidos “Si” y “No”.

intestado integrante Char (20) Indica el estado de un integrante, valores permitidos “Activo” e “Inactivo”

intfechaingreso integrante Date Fecha de ingreso del integrante.

intid integrante Integer Código secuencial de un integrante.

perid integrante Char (20) Indica los datos personales que pertenecen a un integrante.

carid integrante Integer Especifica la carrera la cual pertenece el integrante

proid integrante Integer Especifica el proyecto a cual pertenece el integrante

escid integrante Integer Especifica la escuela la cual pertenece el

integrante

basid linea_base Integer Indica las líneas de investigación que pertenecen a una base de convocatoria.

linid linea_base Integer Indica las líneas de investigación asignadas a una base de convocatoria.

lindescripcion lineainvestigacion Text Descripción de una línea de investigación.

lineliminado lineainvestigacion Char (20) Indica la eliminación lógica de una línea de investigación, valores permitidos “Si” y “No”.

linestado lineainvestigacion Char (20)

Indica el estado de una línea de

investigación, valores permitidos “Activo” e “Inactivo”

linid lineainvestigacion Integer Código secuencial de una línea de investigación.

linnombre lineainvestigacion Char (255) Nombre de una línea de investigación.

menueliminado menu Char (20) Indica la eliminación lógica de un menú, valores permitidos “Si” y “No”.

menuestado menu Char (20) Indica el estado de un menú, valores permitidos “Activo” e “Inactivo”

menuiconourl menu Text Url del icono de un menú.

menuid menu Integer Código secuencial de un menú.

menunombre menu Char (255) Nombre del menú

menuorden menu Integer Orden en el que se visualiza el menú.

menuurl menu Text URL al que redirige un menú.

nivdescripcion nivelinvestigacion Text Descripción de un nivel de investigación, valores permitidos Investigación elemental, o investigación aplicada.

niveliminado nivelinvestigacion Char (20) Indica la eliminación lógica de un nivel de investigación, valores permitidos “Si” y

“No”.

nivestado nivelinvestigacion Char (20) Indica el estado de un nivel de investigación, valores permitidos “Activo” e “Inactivo”.

- 64 -

nivid nivelinvestigacion Integer Código secuencial de un nivel de

investigación.

nivnombre nivelinvestigacion Char (255) Nombre de un nivel de investigación

objid objetivo Integer Código secuencial de un objetivo.

objtipo objetivo Char (20) Tipo de objetivo, valores permitidos,

Objetivo Específico, Objetivo Principal.

proid objetivo Integer Indica los objetivos de un proyecto.

objjerarquia objetivo Text Permite especificar el tipo de objetivo de jerarquía

objlinea objetivo Text Permite especificar el tipo de objetivo

objdefinicion objetivo Text Permite especificar el tipo de objetivo de definición

objfuentes objetivo Text Permite especificar el tipo de objetivo de fuentes

objsupuestos objetivo Text Permite especificar el tipo de objetivo de supuestos

objeliminado objetivo Char (20) Indica la eliminación lógica de un parámetro, valores permitidos “Si” y “No”.

pardescripcion parametro Text Descripción de un parámetro.

pareliminado parametro Char (20) Indica la eliminación lógica de un parámetro, valores permitidos “Si” y “No”.

parestado parametro Char (20) Indica el estado de un parámetro, valores permitidos “Activo” e “Inactivo”

parid parametro Integer Código secuencial de un Parámetro.

parnombre parametro Char (255) Nombre de un parámetro.

parpuntajeminimo parametro Double

precision Puntaje mínimo que se puede sacar en un parámetro padre.

parpuntajetotal parametro Double

precision

Puntaje total que se puede sacar en un parámetro padre, este es la suma de los puntajes máximos de cada parámetro hijo.

pardetid parametro_parametrodetalle

Integer Parámetros asignados bajo un parámetro padre.

pardetorden parametro_parametrodetal

le Integer

Orden en el que aparece el formato en un

formulario de calificación.

pardetpuntajemaximo parametro_parametrodetalle

Double precision

Puntaje máximo que puede sacarse al calificar un parámetro.

pardetpuntajepasar parametro_parametrodetalle

Double precision

Puntaje minino a pasar, al calificar un parámetro.

parid parametro_parametrodetalle

Integer Indica el Parámetro padre de cada parámetro hijo.

pardetcualitativo parametrodetalle Char (10) Indica si el parámetro recibe o no calificaciones cualitativas.

pardetdescripcion parametrodetalle Text Descripción del parámetro.

pardeteliminado parametrodetalle Char (20) Indica la eliminación lógica de un parámetro, valores permitidos “Si” y “No”.

pardetestado parametrodetalle Char (20) Indica el estado de un parámetro, valores permitidos “Activo” e “Inactivo”

pardetid parametrodetalle Integer Código secuencial de un parámetro.

pardetnombre parametrodetalle Char (255) Nombre de un parámetro.

menuid permiso Integer Indica los permisos asignados para acceder a un menú.

permactivacion permiso Boolean Indica si un usuario tiene permisos para activar o inactivar registros.

permeliminacion permiso Boolean Indica si un usuario tiene permisos para eliminar registros.

permeliminado permiso Char (20) Indica la eliminación lógica de un permiso,

valores permitidos “Si” y “No”.

permescritura permiso Boolean Indica si un usuario tiene permisos para crear registros.

permestado permiso Char (20) Indica el estado de un permiso, valores permitidos “Activo” e “Inactivo”

permfechacreacion permiso Date Indica la fecha de creación del permiso.

permid permiso Integer Código secuencial de un permiso.

permimpresion permiso Boolean Indica si un usuario tiene permisos para

- 65 -

imprimir registros.

permlectura permiso Boolean Indica si un usuario tiene permisos para ver registros.

permmodificacion permiso Boolean Indica si un usuario tiene permisos para modificar registros.

rolid permiso Integer Indica los permisos que tiene un rol.

smenuid permiso Integer Indica los permisos que se asignan a un sub menú.

perapellido persona Char (100) Apellido de una persona.

percelular persona Char (20) Celular de una persona.

percorreo persona Char (255) Correo electrónico de una persona.

perdireccion persona Char (255) Dirección de una persona.

pereliminado persona Char (20) Indica la eliminación lógica de una

persona, valores permitidos “Si” y “No”.

perestado persona Char (20) Indica el estado de una persona.

perfechacreacion persona Date Fecha de creación de una persona.

perid persona Char (20) Código secuencial de una persona.

pernombre persona Char (100) Nombre de una persona.

pertelefono persona Char (20) Teléfono de una persona.

carid Personal Integer Indica el cargo que tiene el personal.

perid Personal Char (20) Indica los datos personales que pertenecen al personal del área de investigación.

persid Personal Integer Código secuencial del Personal.

conid proyecto Integer Indica los proyectos que pertenecen a una convocatoria

proaprobacion proyecto Char (100) Indica el estado de un proyecto, valores permitidos, revisión, rechazado, en ejecución y finalizado.

procodigo proyecto Char (100) Código secuencial de un proyecto.

proeliminado proyecto Char (20) Indica la eliminación lógica de un

proyecto, valores permitidos “Si” y “No”.

proestado proyecto Char (20) Indica el estado de un proyecto, valores permitidos “Activo” e “Inactivo”

profechaactualizacion proyecto Date Fecha de la última actualización de un proyecto.

profechacreacion proyecto Date Fecha en la que se creó el proyecto.

proid proyecto Integer Código secuencial de un proyecto.

proidcontinuacion proyecto Integer Indica el código del proyecto de cual es continuación si es que lo es.

pronombre proyecto Char (255) Indica el nombre del proyecto.

propresupuesto proyecto Money Indica el presupuesto del proyecto.

tipinvid proyecto Integer Especifica el tipo de investigación del proyecto

nivid proyecto Integer Especifica el nivel de investigación del proyecto

solid proyecto Integer Indica la solicitud a cual aplica el proyecto

proresumen proyecto Text Resumen del proyecto.

proid revisionpendiente Integer Indica las revisiones pendientes que tiene un proyecto.

revpenid revisionpendiente Integer Código secuencial de una revisión.

rolid revisionpendiente Integer Indica las revisiones pendientes que puede calificar un rol.

roldescripcion rol Text Descripción de un rol “grupo de trabajo”

roleliminado rol Char (20) Indica la eliminación lógica de un rol, valores permitidos “Si” y “No”.

rolestado rol Char (20) Indica el estado un rol, valores permitidos “Activo” e “Inactivo”

rolid rol Integer Código secuencial de un rol.

rolnombre rol Char (255) Nombre del rol “Grupo de trabajo”

intid rolintegrante Integer Indica el rol que cumple un integrante.

roldescripcion rolintegrante Text Descripción de los roles que puede cumplir un integrante.

roleliminado rolintegrante Char (20) Indica la eliminación lógica del rol de un

- 66 -

integrante, valores permitidos “Si” y “No”.

rolestado rolintegrante Char (20) Indica el estado del rol de un integrante, valores permitidos “Activo” e “Inactivo”

rolid rolintegrante Integer Código secuencial del rol de un integrante.

rolnombre rolintegrante Char (255) Nombre del rol de un integrante.

solcalificado solicitud Boolean Indica si un solicitud va a ser calificada o no.

soldescripcion solicitud Text Descripción de una solicitud.

soleliminado solicitud Char (20) Indica la eliminación lógica de una

solicitud, valores permitidos “Si” y “No”.

solestado solicitud Char (20) Indica el estado de una solicitud, valores permitidos “Activo” e “Inactivo”

solid solicitud Integer Código secuencial de una solicitud.

solnombre solicitud Char (255) Nombre de la solicitud.

frtid solicitud_formato Integer Formato al que corresponde cada solicitud.

solid solicitud_formato Integer Indica los formatos que perteneces a una solicitud.

parid solicitud_parametro Integer Indica los parámetros asignados a cada calificación.

solid solicitud_parametro Integer Indica los parámetros asignados para la

calificación de una solicitud.

linid sublinea Integer Indica la línea de investigación a la que pertenece una sub línea de investigación.

subdescripcion sublinea Text Descripción de una solicitud.

subeliminado sublinea Char (20) Indica la eliminación lógica de una sub línea de investigación, valores permitidos “Si” y “No”.

subestado sublinea Char (20) Indica el estado de una sub línea de investigación, valores permitidos “Activo” e “Inactivo”.

subid sublinea Integer Código secuencial de una sub línea de investigación.

subnombre sublinea Char (255) Nombre de una sub línea de investigación.

carid sublinea_carrera Integer Indica las carreras asignadas a una sub línea de investigación.

subid sublinea_carrera Integer Indica las sub línea de investigación que han sido asignadas a una carrera “facultad”.

smenueliminado submenu Char (20) Indica la eliminación lógica de un sub menú, valores permitidos “Si” y “No”.

smenuestado submenu Char (20) Indica el estado de un sub menú, valores permitidos “Activo” e “Inactivo”

smenuiconourl submenu Text Url del icono de un sub menú.

smenuid submenu Integer Código secuencial de un sub menú.

smenunombre submenu Char (255) Nombre del sub menú.

smenuorden submenu Integer Orden en el que se presenta el sub menú.

smenuurl submenu Text Url a la que redirige un sub menú.

tipdescripcion tipobien Char (255) Descripción de un tipo de bien.

tipeliminado tipobien Char (20) Indica la eliminación lógica de un tipo de bien, valores permitidos “Si” y “No”.

tipestado tipobien Char (20) Indica el estado de un tipo de bien, valores permitidos “Activo” e “Inactivo”

tipid tipobien Integer Código secuencial de un tipo de bien.

tipnombre tipobien Char Nombre del tipo de bien.

tipdescripcion tipodocumento Text Descripción de un tipo de documento.

tipeliminado tipodocumento Char (20)

Indica la eliminación lógica de un tipo de

documento, valores permitidos “Si” y “No”.

tipestado tipodocumento Char (20) Indica el estado de un tipo de documento, valores permitidos “Activo” e “Inactivo”

tipid tipodocumento Integer Código secuencial de un tipo de

documento.

tipnombre tipodocumento Char (255) Nombre del tipo de documento.

- 67 -

tipinvdescripcion tipoinvestigacion Text Descripción de un tipo de investigación.

tipinveliminado tipoinvestigacion Char (20) Indica la eliminación lógica de un tipo de investigación., valores permitidos “Si” y “No”.

tipinvestado tipoinvestigacion Char (20) Indica el estado de un tipo de investigación., valores permitidos “Activo”

e “Inactivo”

tipinvid tipoinvestigacion Integer Código secuencial de los tipos de investigación.

tipinvnombre tipoinvestigacion Char (255) Nombre de los tipos de investigación, ejemplo Investigación científica, desarrollo

tecnológico, innovación tecnológica.

tipdescripcion tipoproyecto Text Descripción de un tipo de proyecto, ejemplo proyecto de tesis, de investigación, u otro tipo que quiera ser incluido.

tipeliminado tipoproyecto Char (20) Indica la eliminación lógica.

tipestado tipoproyecto Char (20) Indica el estado de un tipo de proyecto, valores permitidos “Activo” e “Inactivo”

tipid tipoproyecto Integer Código secuencial de un tipo de proyecto.

tipnombre tipoproyecto Char (255) Nombre del tipo de proyecto.

perid usuario Char (20) Indica los datos personales que pertenecen a un usuario.

usuclave usuario Char (255) Clave de acceso al sistema.

usueliminado usuario Char (20) Indica la eliminación lógica de un usuario, valores permitidos “Si” y “No”.

usuestado usuario Char (20) Indica el estado de un usuario, valores permitidos “Activo” e “Inactivo”

usufechacreacion usuario Date Fecha de creación del usuario.

usuid usuario Integer Código secuencial de un usuario.

usunick usuario Char (255) Alias de un usuario en el sistema.

carid usuario_carrera Integer Indica las carreras a las que pertenece cada usuario del sistema.

usuid usuario_carrera Integer Carreras asignadas al usuario.

rolid usuario_rol Integer Indica los roles que tiene un usuario.

usuid usuario_rol Integer Roles asignados al usuario.

3.3.4. RELACIÓN DE DATOS

Los términos utilizados para especificar las relaciones entre las entidades creadas y su

cardinalidad se detallan a continuación:

Cardinalidad: son reglas que debe cumplir una base de datos, entre estas se encuentran 1:1 de

uno a uno, 1: N de uno a varios, N: 1 de varios a uno, N: M de varios a varios.

Identifying: es una relación de uno a muchos, en la que una entidad débil depende de otra.

Non-Identifying: es una relación de uno a mucho, con la diferencia de que no necesita de otra

entidad para poder existir.

En la tabla 19, se especifican las relaciones entre entidades y su Cardinalidad.

TABLA XIX LISTADO DE RELACIONES

Nombre de Constraint Tipo de

Relación Tabla Padre Tabla hija Card.

actividad_cronograma Identifying actividad actividad_cronograma 1:N

actividad_solicitud Non-identifying solicitud actividad_cronograma 1:N

ajuste_calificacion Non-identifying calificacion ajuste 1:N

base_linea Identifying baseconvocatoria linea_base 1:N

base_solicitudinicial Identifying baseconvocatoria base_solicitud 1:N

bien_serie Identifying Bien Serie 1:N

- 68 -

biendetalle_serie Identifying Serie certificadodetalle 1:N

calificacion_calificaciondetall

e Identifying calificacion calificaciondetalle 1:N

calificacion_parametrodetalle Non-identifying parametro_paramet

rodetalle calificaciondetalle 1:N

calificacion_usuario Non-identifying usuario calificacion 1:N

Cargo_Personal Non-identifying Cargo Personal 1:N

carrera_concovatoria Identifying carrera convocatoria_carrera 1:N

carrera_escuela Non-identifying escuela carrera 1:N

carrera_sublinea Identifying carrera sublinea_carrera 1:N

carrera_usuario Identifying carrera usuario_carrera 1:N

certificado_certificadodetalle Identifying certificado certificadodetalle 1:N

certificado_personal Non-identifying Personal certificado 1:N

convocatoria_base Non-identifying baseconvocatoria convocatoria 1:N

convocatoria_carrera Identifying convocatoria convocatoria_carrera 1:N

convocatoria_cronograma Non-identifying cronograma convocatoria 1:N

convocatoria_tipoproyecto Non-identifying tipoproyecto convocatoria 1:N

cronograma_actividad Identifying cronograma actividad_cronograma 1:N

documento_archivo Non-identifying archivo documento 1:N

documento_proyecto Non-identifying proyecto documento 1:N

documento_solicitud Non-identifying solicitud documento 1:N

documento_tipodocumento Non-identifying tipodocumento documento 1:N

Formato_Solicitud Identifying formato solicitud_formato 1:N

formatos_archivos Non-identifying archivo formato 1:N

integrante_rol Non-identifying integrante rolintegrante 1:N

integrantepersona Non-identifying persona integrante 1:N

linea_base Identifying lineainvestigacion linea_base 1:N

menu_permisos Non-identifying menu permiso 1:N

nivel_proyecto Identifying nivelinvestigacion nivelinvestigacion_proyecto 1:N

objetivo_proyecto Non-identifying proyecto objetivo 1:N

parametro_parametrodetalle Identifying parametro parametro_parametrodetalle 1:N

parametro_solicitud Identifying parametro solicitud_parametro 1:N

parametrodetalle_parametro Identifying parametrodetalle parametro_parametrodetalle 1:N

personal_persona Non-identifying persona Personal 1:N

proyecto_ajustes Non-identifying proyecto ajuste 1:N

proyecto_convocatoria Non-identifying convocatoria proyecto 1:N

proyecto_integrante Identifying proyecto integrante 1:N

proyecto_nivel Identifying proyecto nivelinvestigacion 1:N

proyecto_solicitud Identifying proyecto solicitud 1:N

proyecto_tipoinvestigacion Identifying proyecto tipoinvestigacion 1:N

revisionpendiente_calificacio

n Non-identifying revisionpendiente calificacion 1:N

revisionpendiente_proyecto Non-identifying proyecto revisionpendiente 1:N

rol_premisos Non-identifying rol permiso 1:N

Rol_Revision Non-identifying rol revisionpendiente 1:N

rol_usuario Identifying rol usuario_rol 1:N

solicitud_calificacion Non-identifying solicitud calificacion 1:N

solicitud_convocatoria Identifying solicitud base_solicitud 1:N

Solicitud_Formato Identifying solicitud solicitud_formato 1:N

solicitud_parametro Identifying solicitud solicitud_parametro 1:N

sublinea_carrera Identifying sublinea sublinea_carrera 1:N

sublinea_linea Non-identifying lineainvestigacion sublinea 1:N

submenu_permisos Non-identifying submenu permiso 1:N

tipobien_bien Non-identifying tipobien bien 1:N

usuario_carrera Identifying usuario usuario_carrera 1:N

- 69 -

usuario_control Identifying usuario control 1:N

usuario_persona Non-identifying persona usuario 1:N

usuario_rol Identifying usuario usuario_rol 1:N

3.3.5. DIAGRAMA DE BASE DE DATOS

Fig. 42 Diagrama Base de Datos

- 70 -

4. CAPITULO 4. DISEÑO

4.1. ARQUITECTURA DE MODELADO DE SERVICIOS

Para el desarrollo estructurado del sistema y para facilitar el mantenimiento se implementa una

arquitectura de desarrollo conocida como modelo de servicios, esta arquitectura está basada en otra

arquitectura conocida como modelo vista controlador (MVC), el cual es un patrón que permite

separar la interfaz del usuario de la lógica del negocio, y brinda aspectos de reutilización y

flexibilidad [19], este patrón es implementado para el desarrollo de aplicaciones web, y existen

diversos frameworks que trabajan con esta metodología, entre ellos esta Spring, asp.net MVC,

Struts, Primefaces entre otros.

Controlador: En esta capa se maneja toda la lógica del negocio, y se controlan los diferentes

eventos que ejecuta el usuario reaccionando a la petición del cliente, ejecutando la acción adecuada y

creando el modelo pertinente, convirtiéndose en eje principal de la arquitectura, ésta se comunica

con el modelo y se encarga de mostrar los resultados a través de la vista [20].

Modelo: En esta capa se define las entidades que pertenecen a la base de datos, es muy

importante, ya que permite el uso de cada tabla y campo de la base de datos, es aquel que contiene el

núcleo de la funcionabilidad y que encapsula el estado de la aplicación, además este no sabe nada es

independiente del Controlador y Vista, la ventaja de implementar JAVA es que ofrece la generación

de este modelo de manera automática y estandarizada, permitiendo agilizar el trabajo del

programador [20].

Vista: La vista es quien controla las interfaces gráficas y se encarga de mostrar la información al

usuario, es decir, la presentación del modelo [20].

Estas tres capas son manejadas por ambas arquitecturas, la diferencia se da en la arquitectura de

modelo de servicios, ya que ésta implementa una capa adicional conocida con el nombre de servicio,

en esta capa se maneja las conexiones a la base de datos, el control de la persistencia e implementa

todo servicio adicional que no requiere de una validación complementaria la cual pueda ser usado

por cualquiera de las capas anteriores, en la figura 43, se especifica la comunicación que existe entre

estas capas, la comunicación de estas indica que la más importante es la del modelo, ya que todas las

capas dependen de esta, el inicio de toda actividad empieza a través de la vista, la cual realiza una

solicitud al controlador, en donde aplica las reglas del negocio para validar la petición, cuando la

solicitud es validad este la transfiere al servicio o la realiza el mismo según sea la necesidad y

devuelve un estado de la transacción, la cual es transmitida hacia el usuario a través de la misma

capa por la cual se hizo la solicitud en este caso la vista.

Fig. 43 Comunicación Capas De Arquitectura

- 71 -

4.2. DISEÑO DE INTERFAZ GRÁFICA

Las interfaces que se van a implementar o desarrollar en el sistema deben ser intuitivas y

adaptables, brindando un flujo de trabajo estándar para que el manejo de las interfaces graficas sea

mucho más sencillo, en base a esto se plantea un diseño en el cual la capa de la vista se divide en

cinco sub capas básicas, pero el número puede incrementarse o disminuir dependiendo de los

requerimientos de la interfaz a realizar, las cuales están claramente identificadas con los siguientes

nombres index, crear, modificar, ver, eliminar físico y eliminar lógico, se ha dividido la vista para

facilitar el desarrollo y organización de la aplicación, pero al momento de ser visualizadas trabajan

de forma integrada como si se tratase de una sola vista, este estándar es definido para formulario

sencillos que solo requieren realizar procesos de creación, actualización y modificación (CRUD -

Crear, Obtener, Actualizar y Borrar), las vistas heredan los componentes de la vista padre, esta vista

está identificada con el nombre de index, el cual es el formulario principal de las cinco capas y el

que permite la comunicación entre todas las capas de la vista de manera intuitiva según indica [21].

4.2.1. INTERFAZ DE INICIO DE APLICACIÓN

Todo sistema debe contener una pantalla inicial por la cual se podrá acceder a la aplicación, esta

interfaz es muy importante ya que se tendrá el primer filtro de seguridad y control, donde se validará

el ingreso del usuario, en la cual se obliga a especificar el usuario y contraseña para acceder a los

diferentes módulos del sistema asignados al usuario, mediante el control y validacion interna del rol

y permisos asignados al usuario que pretende ingresar al sistema.

Así mismo esta interfaz inicial dará la facilidad de registrar nuevos usuarios, en la figura 44, se

visualiza las opciones antes descritas.

Fig. 44 Interfaz Inicio De Aplicación

4.2.2. REGISTRO NUEVO USUARIO

Todo sistema informático, sea orientado a la web o de escritorio debe de existir una interfaz para

registrar o crear nuevos usuario quienes en el futuro van a acceder a la aplicación, en la figura 45, se

da a conocer dicha interfaz.

Como se sabe un usuario consta de informacion básica a registrar tales como el número de

cédula, nombres, apellidos, dirección, teléfono, celular, de igual manera de un correo electrónico,

que en la mayoría de los casos es el nombre de usuario asignado para acceder a una aplicación, en

- 72 -

otras aplicaciones también se le conoce como Nick, además se deberá ingresar un alias o un

sobrenombre con el cual será identificado el usuario entre los demás, es importante especificar una

contraseña de acceso con la cual ingresará al sistema.

Fig. 45 Interfaz Registro De Usuario

4.2.3. PANTALLA PRINCIPAL

La aplicación posee una interfaz en la cual el usuario podrá visualizar las opciones y accesos

asignadas en el sistema, esto está definido por el rol y los permisos que se hayan asignado, en la

figura 46, se visualizará la pantalla principal de la aplicación en la cual se activará los diferentes

menús con sus respectivos submenús los cuales accederán a los diferentes módulos e interfaces que

posee la aplicación.

- 73 -

Fig. 46 Interfaz Principal

4.2.4. ESPECIFICACIÓN DE LAS DIVISIONES DE SUB CAPAS DE UNA

VISTA

4.2.5. INDEX

El formulario index es la capa principal de cada formulario web, ya que este permite la

comunicación y agrupación de las demás capas, en esta capa se compone de un listado de la

información de la entidad a la que representa, y de botones que permiten la comunicación con las

demás capas, en esta capa se lleva el control de los permisos que tienen cada usuario, especificando

qué procesos puede realizar el usuario dependiendo de los permisos que se los ha asignado, entre

los permisos estándares que se controlan está la creación, modificación, activación o desactivación

de registros, la eliminación y el ver en detalle cada registro seleccionado de la entidad a la que

representa el formulario, en la figura 47, se indica las opciones que brinda esta capa.

La capa index también está conformada, integrada y desarrollada con campos de buscada rápido

ya sea global o columnas especificadas en el datatable principal, esto para facilitar el manejo de la

misma [21].

Fig. 47 Formulario Index

- 74 -

4.2.6. CREAR

La capa de crear permite al usuario ingresar nuevos registros al sistema, los cuales son

debidamente validados, para evitar datos incorrectos o duplicidad de la información, en esta capa

también se puede realizar cualquier lógica del negocio, ya sean búsquedas, carga automática de

información, etc. Dependiendo de las necesidades que requiera la capa de creación podrá cambiar su

presentación. En la figura 48, se observa el diseño de esta capa para un mantenimiento básico.

Fig. 48 Formulario de Creación

4.2.7. MODIFICAR

La funcionabilidad de esta capa se base en la selección de un registro ya creado el cual se

visualiza en un datatable, y sobre este realizar modificación de la información, de igual forma que la

capa de crear, en este formulario también se valida la información y lógica del negocio, en la figura

49, se observa la vista de esta capa, la cual es similar a la de crear pero el proceso que realiza es

diferente.

Fig. 49 Formulario de Modificación

4.2.8. ELIMINAR

Esta es una capa de confirmación que visualizará dos opciones o procesos a realizar, realizando

una verificación de la eliminación y ejecutando el proceso con un solo clic, en la figura 50, se

observa el diseño de la capa.

Fig. 50 Formulario de Eliminación

- 75 -

4.2.9. VER

Al igual que la capa de modificar, ésta necesita que un registro esté previamente seleccionado,

esta capa permite realizar una visualización en detalle del registro seleccionado, indicando los

diferentes valores que fueron ingresados para cada uno de los atributos de la entidad, en esta capa se

puede utilizar cualquier objeto el cual facilite la visualización de datos, en la figura 51, se observa el

diseño da la capa.

Fig. 51 Formulario de Visualización

- 76 -

5. CAPITULO 5. IMPLEMENTACIÓN

5.1. CONSTRUCCIÓN

Para el desarrollo de la aplicación se implementó la persistencia java, que es conocida como JPA

(Java Persintence Api), la cual permite la interacción con la base de datos aplicando las ventajas que

posee la Programación Orientada a Objetos (POO), de igual forma posee un lenguaje JPQL (Java

Persistence Query Language) , que permite realizar todo tipo de transacción con la base de datos,

por lo cual esta herramienta permite agilizar el trabajo del desarrollador y brinda una integración

completa con el framework Primefaces.

Algo fundamental en todo sistema de software es la manera de como conectarse a la base de

datos, en nuestro sistema la conexión se determina de la siguiente manera:

package servicios;

import java.io.File;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.faces.context.FacesContext;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

import javax.persistence.Query;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Control;

import modelo.ControlPK;

import modelo.Usuario;

import org.primefaces.model.UploadedFile;

public abstract class Servicio {

Private EntityManager em; //crear el objeto de conexión

private String createEntityManger() {

try {

EntityManagerFactory Factory=

Persistence.createEntityManagerFactory("gestioninvestigacionPU"); //se busca en el archivo de

configuración persintece.xml el nombre de la unidad de persistencia.

this.em= factory.createEntityManager();

- 77 -

return "Conexion establecida";

}

catch (Exception e) {

return "Error 00: No se pudo establecer la conexion";

}

}

//Para poder usar la conexión cada vez que se necesite se realiza un constructor del entity

manager, el cual me devuelve la conexión que se establece al acceder a la clase.

public EntityManager getEm() {

return em;

}

}

Toda transacción a realizar hace uso del entity manager, este permite realizar diferentes

transacciones con la base de datos, por ejemplo para la obtención de información de la base de datos

en este caso la finalidad es obtener todos los registros almacenados en una tabla, lo cual logramos

implementando el siguiente código fuente.

package servicios;

import java.io.File;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.faces.context.FacesContext;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

import javax.persistence.Query;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Control;

import modelo.ControlPK;

import modelo.Usuario;

import org.primefaces.model.UploadedFile;

public abstract class Servicio {

public Collection Cargar(String Entidad){

try {

- 78 -

Query objQuery= this.getEm().createNamedQuery(Entidad + ".findAll");

return objQuery.getResultList();

}

catch (Exception e) {

return null;

}

}

}

Cuando haya la necesidad de realizar consultas más específicas hay que implementar sentencias

más largas con mayor grado de complejidad, pero cuando se conoce el lenguaje resultan ser igual de

fáciles como hacer consultas SQL, un ejemplo de una consulta más compleja es cuando se requiere

sacar información de dos tablas, implementando el uso de INNER JOIN.

package servicios;

import java.util.Collection;

import java.util.List;

import javax.persistence.Query;

import modelo.Escuela;

import modelo.Carrera;

public class CarreraServicio extends Servicio {

private List cargarNoIncluidoUsuario (Integer croid,Integer linid) {

try {

getEm().getTransaction().begin();

Query objQuery=this.getEm().createQuery("SELECT t from Carrera as t where

LOWER(t.carestado)='activo' and LOWER (t.careliminado)='no' and t.carid NOT IN (select a.carid

from Carrera as a INNER JOIN a.usuarioCollection as c where c.usuid=:usuid) and

t.escid.escid=:escid ORDER BY t.carnombre ASC ");

objQuery.setParameter("usuid", croid);

objQuery.setParameter("escid", linid);

getEm().getTransaction().commit();

return objQuery.getResultList();

}

catch (Exception e) {

return null;

}

}

}

Para almacenar y realizar las diferentes transacciones de información en el sistema se

implementan líneas de código reducidas en una clase general, con la finalidad de evitar el uso de

procedimientos almacenados y sentencias largas de insert, update y delete, antes de implementar los

métodos que ofrece la persistencia se debe generar el objeto con el cual se va a realizar la

- 79 -

transacción, todo este proceso y funcionabilidad de información se implementa de la siguiente

manera.

package servicios;

import java.io.File;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.faces.context.FacesContext;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

import javax.persistence.Query;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Control;

import modelo.ControlPK;

import modelo.Usuario;

import org.primefaces.model.UploadedFile;

public abstract class Servicio {

public String Insertar (Object objInsertar) {

try {

//Si la transacción no está iniciada desde antes de llamar a este método se inicia y se

cierra caso contrario se inicia y se cierra desde el método que lo llame

boolean cerrarTransaccion=false;

if(!this.getEm().getTransaction().isActive()) {

IniciarTransaccion();

cerrarTransaccion=true;

}

this.getEm().persist(objInsertar);

if (cerrarTransaccion==true) {

return CerrarTransaccion("crear");

}

else {

return "";

- 80 -

}

}

catch(Exception e) {

RollbackTransaccion();

return "Error 01: Error de ingreso de informacion, verifique los datos e intente nuevamente";

}

}

}

Para actualizar información ya existentes en la base de datos se realiza utilizando la siguiente

consulta.

package servicios;

import java.io.File;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.faces.context.FacesContext;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

import javax.persistence.Query;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Control;

import modelo.ControlPK;

import modelo.Usuario;

import org.primefaces.model.UploadedFile;

public abstract class Servicio {

public String Actualizar (Object objActualizar) {

try {

boolean cerrarTransaccion=false;

if(!this.getEm().getTransaction().isActive()) {

IniciarTransaccion();

cerrarTransaccion=true;

}

- 81 -

this.getEm().flush();

this.getEm().refresh(objActualizar);

if (cerrarTransaccion==true) {

return CerrarTransaccion("actualizar");

}

else {

return "";

}

}

catch (Exception e) {

RollbackTransaccion();

return "Error 02: Error al modificar, verifique los datos e intente nuevamente";

}

}

}

Para eliminar información se ha creado dos formas, la una que se trata de una eliminación lógica

y la otra una eliminación física las cuales se detalla a continuación.

package servicios;

import java.io.File;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.faces.context.FacesContext;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

import javax.persistence.Query;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Control;

import modelo.ControlPK;

import modelo.Usuario;

import org.primefaces.model.UploadedFile;

public abstract class Servicio {

- 82 -

public String EliminarLogicamente (Object objActualizar) {

try {

boolean cerrarTransaccion=false;

if(!this.getEm().getTransaction().isActive()) {

IniciarTransaccion();

cerrarTransaccion=true;

}

this.getEm().flush();

this.getEm().refresh(objActualizar);

if (cerrarTransaccion==true) {

return CerrarTransaccion("eliminar logicamente");

}

else {

return "";

}

}

catch (Exception e) {

RollbackTransaccion();

return "Error 05: Error al eliminar, intente nuevamente";

}

}

public String Eliminar (Object objEliminar) {

try {

boolean cerrarTransaccion=false;

if(!this.getEm().getTransaction().isActive()) {

IniciarTransaccion();

cerrarTransaccion=true;

}

this.getEm().remove(objEliminar);

if (cerrarTransaccion==true) {

return CerrarTransaccion("eliminar fisicamente");

}

else {

return "";

}

}

catch(Exception e) {

RollbackTransaccion();

return "Error 06: Error al eliminar, intente nuevamente";

- 83 -

}

}

}

La funcionabilidad principal de un sistema de software es la dinámica que se implementa al

cargar los diferentes menús de acceso, los cuales se visualizarán dependiendo del rol y los permisos

de acceso, este menú será accesible en la página inicial de la aplicación (figura 46), para lograr esta

característica se desarrolló el código fuente que se detalla a continuación.

package controlador;

import java.util.List;

import javax.faces.bean.ManagedBean;

import javax.faces.bean.SessionScoped;

import modelo.Menu;

import org.primefaces.component.menuitem.MenuItem;

import org.primefaces.component.submenu.Submenu;

import org.primefaces.model.DefaultMenuModel;

import org.primefaces.model.MenuModel;

import servicios.MenuServicio;

import servicios.SubmenuServicio;

@ManagedBean

@SessionScoped

public class estilospaginaControlador {

public List <Menu> ListarOP;

private MenuServicio ServicioOP;

public void ListadoOpciones() {

ServicioOP= new MenuServicio();

ListarOP=(List<Menu>) ServicioOP.cargarMenuUsuario();

}

public void setSimpleMenuModel(MenuModel simpleMenuModel) {

this.simpleMenuModel = simpleMenuModel;

}

public MenuModel getSimpleMenuModel() {

simpleMenuModel=new DefaultMenuModel();

ListadoOpciones();

Integer IdMenuEvaluado=0;

String [] IdMenuEvaluados= new String [ListarOP.size()];//se crea un vector para guardar los

menus que ya se analizaron y no repetirlos

Integer Contador=0;

- 84 -

Integer IdRol=ServicioOP.IdRol();

for(Menu objMenu : ListarOP) {

boolean validar=true;

IdMenuEvaluado=objMenu.getMenuid();

for (String validacion:IdMenuEvaluados) {

if(validacion == null ? IdMenuEvaluado.toString() == null :

validacion.equals(IdMenuEvaluado.toString())) {

validar=false;

}

}

if (validar) {

IdMenuEvaluados[Contador]=IdMenuEvaluado.toString();

if ("".equals(objMenu.getMenuurl())) {

Submenu menu = new Submenu();

menu.setLabel(objMenu.getMenunombre());

SubmenuServicio objSubmenu= new SubmenuServicio();

List<modelo.Submenu>listadoSmenu=

objSubmenu.cargarSubMenuUsuario(objMenu.getMenuid());

for (modelo.Submenu objMenuInterno : listadoSmenu) {

MenuItem smenuItem = new MenuItem();

smenuItem.setValue(objMenuInterno.getSmenunombre());

if (!"".equals(objMenuInterno.getSmenuurl())) {

smenuItem.setUrl(objMenuInterno.getSmenuurl());

}

else {

smenuItem.setUrl("#");

}

smenuItem.setIcon(objMenuInterno.getSmenuiconourl());

smenuItem.setStyle("width:100%");

menu.getChildren().add(smenuItem);

}

simpleMenuModel.addSubmenu(menu);

}

else {

MenuItem menuItem = new MenuItem();

menuItem.setValue(objMenu.getMenunombre());

if (!"".equals(objMenu.getMenuurl())) {

menuItem.setUrl(objMenu.getMenuurl());

}

- 85 -

else {

menuItem.setUrl("#");

}

menuItem.setIcon(objMenu.getMenuiconourl());

simpleMenuModel.addMenuItem(menuItem);

}

Contador++;

}

}

return simpleMenuModel;

}

}

El código fuente descrito anteriormente especifica como cargar los menús y submenús asignados

a un usuario los cuales podrá utilizar dependiendo del rol y permisos asignados, el código fuente que

se detalla a continuación permite acceder a la transacción asignada a un menú o submenú que será

seleccionado por el usuario.

package controlador;

import java.io.IOException;

import java.util.List;

import java.util.logging.Level;

import java.util.logging.Logger;

import javax.faces.bean.ManagedBean;

import javax.faces.bean.SessionScoped;

import javax.faces.context.FacesContext;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Rol;

import modelo.Usuario;

import servicios.RolServicio;

import servicios.UsuarioServicio;

@ManagedBean

@SessionScoped

public class LoginControlador extends UsuarioControladorLogin{

public void redirigir(String ruta){

try {

FacesContext.getCurrentInstance().getExternalContext().redirect(ruta);

} catch (IOException ex) {

Logger.getLogger(LoginControlador.class.getName()).log(Level.SEVERE, null, ex);

}

}

- 86 -

}

En un sistema de software es primordial comprobar la veracidad de los datos ingresados al iniciar

sesión en la aplicación, para comprobar si los datos son correctos al iniciar sesión en la aplicación de

software se desarrolló el siguiente código fuente.

package controlador;

import java.io.IOException;

import java.util.List;

import java.util.logging.Level;

import java.util.logging.Logger;

import javax.faces.bean.ManagedBean;

import javax.faces.bean.SessionScoped;

import javax.faces.context.FacesContext;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Rol;

import modelo.Usuario;

import servicios.RolServicio;

import servicios.UsuarioServicio;

@ManagedBean

@SessionScoped

public class LoginControlador extends UsuarioControladorLogin{

public void login() {

Servicio= new UsuarioServicio();

Listar=(List<Usuario>)

Servicio.buscarPorCorreoClave(getPersonacorreo(),getUsuarioclave());

if (!Listar.isEmpty()) {

HttpServletRequest request = (HttpServletRequest)

FacesContext.getCurrentInstance().getExternalContext().getRequest();

HttpSession session = request.getSession(true);

session.setAttribute("usuario", Listar.get(0));

session.setAttribute("rol", 0);

setUsuarionick(Listar.get(0).getUsunick());

try {

FacesContext.getCurrentInstance().getExternalContext().redirect("estilos/principal.xhtml");

}

catch (IOException ex) {

Logger.getLogger(LoginControlador.class.getName()).log(Level.SEVERE, null, ex);

}

}

else {

- 87 -

setEstadologin("El usuario o contraseña son incorrectos");

}

}

}

package servicios;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.persistence.Query;

import modelo.Persona;

import modelo.Usuario;

public class UsuarioServicio extends Servicio {

public List buscarPorCorreoClave (Object... args) {

Query objQuery= this.getEm().createQuery("SELECT U from Usuario as U INNER JOIN

U.perid as P where p.percorreo=:percorreo and u.usuclave=:usuclave and

LOWER(u.usuestado)='activo' and LOWER(u.usueliminado)='no' and

LOWER(p.perestado)='activo' and LOWER(p.pereliminado)='no'");

objQuery.setParameter("percorreo", args[0].toString());

objQuery.setParameter("usuclave", args[1].toString());

return objQuery.getResultList();

}

}

Lo fundamental que se debe conocer además de todo lo detallado anteriormente es el rol que

posee el usuario que acaba de ingresar al sistema, lo cual se lo consigue con el código que se detalla

a continuación.

package controlador;

import java.io.IOException;

import java.util.List;

import java.util.logging.Level;

import java.util.logging.Logger;

import javax.faces.bean.ManagedBean;

import javax.faces.bean.SessionScoped;

import javax.faces.context.FacesContext;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Rol;

import modelo.Usuario;

import servicios.RolServicio;

import servicios.UsuarioServicio;

@ManagedBean

- 88 -

@SessionScoped

public class LoginControlador extends UsuarioControladorLogin{

public boolean listarRol()

{

boolean respuesta=false;

boolean sessionactiva=true;

HttpServletRequest request = (HttpServletRequest)

FacesContext.getCurrentInstance().getExternalContext().getRequest();

HttpSession session = request.getSession(true);

try {

if (session.getAttribute("rol")!=null){

if ("0".equals(session.getAttribute("rol").toString())) {

if (getListaOpcion().size()>1){

respuesta= true;

}

else {

asignarRol(listaOpcion.get(0).getRolid());

}

}

}

else {

sessionactiva=false;

}

return respuesta;

}

catch (Exception e) {

return respuesta;

}

finally {

if(sessionactiva==false) {

redirigir("../index.xhtml");

}

}

}

}

Para ejecutar las diferentes acciones y sentencias a la base de datos, utilizando la persistencia

JPA, es realizado mediante un commit y en el caso que exista un error al ingresar la información se

debe reversar las acciones mediante un Rollback, esto se realiza de la siguiente manera.

package servicios;

import java.io.File;

- 89 -

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Collection;

import java.util.Date;

import java.util.List;

import javax.faces.context.FacesContext;

import javax.persistence.EntityManager;

import javax.persistence.EntityManagerFactory;

import javax.persistence.Persistence;

import javax.persistence.Query;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

import modelo.Control;

import modelo.ControlPK;

import modelo.Usuario;

import org.primefaces.model.UploadedFile;

public abstract class Servicio {

public String CerrarTransaccion(String Transaccion) {

try {

getEm().getTransaction().commit();

if("crear".equals(Transaccion)){return "El registro se creo correctamente";}

else if("actualizar".equals(Transaccion)) {return "El registro se actualizo correctamente";}

else if("activar".equals(Transaccion)) {return "El registro se activo correctamente";}

else if("desactivar".equals(Transaccion)) {return "El registro se desactivo correctamente";}

else if("eliminar logicamente".equals(Transaccion)) {return "El registro se elimino

correctamente";}

else if("eliminar fisicamente".equals(Transaccion)) {return "El registro se elimino

correctamente";}

else if("listar".equals(Transaccion)) {return "El registro se listo correctamente";}

else {return "Error 07: Transaccion no permitida";}

} catch (Exception e) {

RollbackTransaccion();

if("crear".equals(Transaccion)){return "Error 01: Error de ingreso de informacion, verifique los

datos e intente nuevamente";}

else if("actualizar".equals(Transaccion)) {return "Error 02: Error al modificar, verifique los datos

e intente nuevamente";}

else if("activar".equals(Transaccion)) {return "Error 03: Error al activar, intente nuevamente";}

- 90 -

else if("desactivar".equals(Transaccion)) {return "Error 04: Error al desactivar, intente

nuevamente";}

else if("eliminar logicamente".equals(Transaccion)) {return "Error 05: Error al eliminar, intente

nuevamente";}

else if("eliminar fisicamente".equals(Transaccion)) {return "Error 05: Error al eliminar, intente

nuevamente";}

else if("listar".equals(Transaccion)) {return "Error 06: Error al listar, intente nuevamente";}

else {return "Error 07: Transaccion no permitida";}

}

}

}

Para la generación y visualización de reportes en el sistema se desarrolló varias líneas de código,

en las cuales sobre salen las variables DRIVER, RUTA, USER y PASSWORD, en las cuales se

almacenan los parámetros básicos de conexión con la base de datos para la obtención de la

información para ser visualizada en los reportes, el código para esta finalidad se detalla a

continuación.

public static final String DRIVER="org.postgresql.Driver";

public static final String RUTA="jdbc:postgresql://localhost:5432/dbinvestigacion";

public static final String USER="postgres";

public static final String PASSWORD="admin";

public static Connection CONEXION;

El método principal y estándar para la generación de cualquier reporte ya sea este con o sin

parámetros se describe en el siguiente fragmento de código fuente.

public void startReport(String nameReport, Map ParametrosRep) throws SQLException{

try {

Class.forName(DRIVER).newInstance();

CONEXION=DriverManager.getConnection(RUTA, USER, PASSWORD);

System.out.println("conexion exitosa");

try {

URL

urlMaestro=getClass().getClassLoader().getResource("reportes/"+nameReport+".jasper");

JasperReport reporte= null;

reporte=(JasperReport) JRLoader.loadObject(urlMaestro);

//Map param=new HashMap();

//param.put("proyecto", "codigo");//nombre de parametro, variable

JasperPrint jasperPrint= JasperFillManager.fillReport(reporte,

ParametrosRep,CONEXION);

JasperViewer visor=new JasperViewer(jasperPrint,false);

- 91 -

visor.setTitle("GESTION DE PROYECTOS");

visor.setVisible(true);

CONEXION.close();

}

catch (Exception e) {

System.out.println(e.getMessage());

CONEXION.close();

}

} catch (Exception e) {

System.out.println(e.getMessage());

CONEXION.close();

}

}

Para acceder al procedimiento estándar de visualización y carga de los reportes desde un

mantenimiento se lo realiza empleando el siguiente código, en el cuál se especifica el nombre del

reporte a utilizar, de igual manera se indica los parámetros si los posee.

Código Fuente para reportes con parámetros de entrada.

String name="LOG";

Map parametro= new HashMap();

parametro.put("usuarioid", selectOpcionUsuario);

parametro.put("fdesde", fecdesde.toLocaleString());

parametro.put("fhasta", fechasta.toLocaleString());

Servicio.generarReporteParametro(name, parametro);

Código Fuente para reportes sin parámetros.

Servicio=new RepadministracionServicio();

String name="USUARIOS";

Servicio.generarReporte(name);

5.1.1. ESPECIFICACIÓN DEL USO DE LA CAPA CONTROLADOR

Esta capa recibe la petición de ejecución de diferentes procesos a través de la vista, al recibir esta

petición se encarga de validarla y devolver un resultado a la capa de la vista, para que se pueda

establecer la comunicación con esta capa, la vista debe manejar accesos directos a esta capa y poder

ejecutar los diferentes eventos, para la ejecución del CRUD implementando esta capa se establecen

métodos que permitan validar los valores a ingresar y comunicarse con la capa de servicios, estos

métodos son identificados en minúsculas, debido a que el framework Primefaces solo se comunica

con ellos si cumplen con esta condición, los métodos que se implementan son listar, crear, modificar,

eliminar, validar en donde cada uno cumple una función específica, el único método básico que

aplica la lógica del negocio es de validar, pero pueden existir otros métodos como procesos de

comprobación de información ya existente o creación de procedimientos que devuelvan una lista de

resultados según las necesidades, ya que en este se especifica que valores se deben guardar y qué

condiciones deben cumplir, los otros métodos mencionados hacen uso de éste para poder especificar

- 92 -

si pueden o no ejecutar la petición, cada formulario contiene estos métodos y sus nombres son los

mismos para facilitar el mantenimiento de esta capa.

Método Listar: Este método solicita un listado de datos de la entidad que se le especifique, este

método es invocado al momento de que el usuario carga la vista.

Método Crear: Permite realizar él envió de los datos que se desean registrar en la base de datos,

este método es invocado cuando el usuario solicita el ingreso de un nuevo registro.

Método Modificar: El usuario cuando hace la selección de un registro ya creado y desea

modificarlo el sistema carga la información respectiva y el usuario ingresa los valores a modificar y

realiza la petición, luego el método realiza una validación de los valores ingresado y los envía al

método de modificación de la capa de servicio.

Método Eliminar: realiza él envió del código del registro que se desea eliminar.

Es importante resaltar que esta capa no inserta, ni actualiza los datos, el único trabajo de esta

capa es realizar la validación de los datos y transmitir la solicitud a la clase de la capa de servicios

encargada de realizar la petición.

5.1.2. FUNCIÓN DE LA CAPA DE SERVICIOS

Esta capa se encarga de ejecutar las peticiones que recibe del controlador, los métodos más

comunes son los que interactúan con la base de datos, los cuales implementan la persistencia java.

Esta capa hace uso del modelo para generar un objeto y especificar los datos que se van a ingresar en

la base de datos, también se pueden especificar otro tipo de métodos, algunos métodos que se

implementaron para el desarrollo de la aplicación de la gestión proyectos de investigación son:

Manejo de Archivos: este clase contiene los algoritmos necesarios para subir un archivo al

servidor, modificarlos o eliminarlos si es necesario.

Servicios para Entidad: Estos servicios manejan la información de la base de datos, al igual que

el controlador implementa métodos de listar, crear, modificar, eliminar, con la diferencia que estos

métodos tienen la primera letra en mayúscula para diferenciar del nombre que tiene el método en la

capa del controlador, cada método genera un objeto y luego realiza una petición a un servicio padre.

5.1.3. CAPA DEL MODELADO

Es la capa principal de la arquitectura, la cual permite la representación de la base de datos en

objetos, al cual se hace referencia y accediendo al mismo, gracias al asistente guiado el cual es

conocido en java como entity class, al utilizar esta herramienta las clases se crean con normativas y

estándares de programación, y está desarrollado para implementarse fácilmente con la arquitectura

MVC, en este caso modelo de servicios, el cual ofrece al programador un enlace directo a la base de

datos sin tener que realizar procesos complicados de conexión a la base de datos, la conexión se

realiza implementado un ODBC de PostgreSQL.

5.1.4. MODULO DE ADMINISTRACIÓN

Este módulo realiza la integración de varias entidades de la base de datos, como lo son: submenú,

menú, permiso, usuario, rol, persona, control, con éste módulo se realiza el control de acceso al

sistema, especificando las opciones o procesos que cada usuario puede realizar, el módulo se

compone de varios formularios que permiten controlar y acceder al sistema de manera eficiente,

también el registro de las acciones que son ejecutadas en el sistema, con el fin de establecer un

proceso de auditoría que debe llevar todo sistema informático, el proceso de auditoría es almacenado

en la base de datos en la tabla control, en la cual se especifica el usuario que realiza la acción, la

fecha y hora de la transacción, aquel proceso es manejado automáticamente por el sistema y no

requiere ser activado por un usuario para ser ejecutado, en la figura 52, se observa la interacción del

- 93 -

usuario con el módulo de administración, y la forma de iteración entre componentes que realizan el

proceso.

Fig. 52 Componentes Módulo de Administración

Para el acceso al sistema se especificó dos métodos de acceso, a través del registro de usuarios

los cuales van a trabajar bajo el rol de investigadores, éste grupo de trabajo solo tendrán acceso a

ciertas opciones del sistema, la otra forma de acceso es creando el usuario y luego asignándole el

respectivo rol que tendrá en el sistema, para realizar esta creación es necesario ser un usuario con

acceso al mantenimiento de usuarios del sistema.

5.1.5. MODULO DE GESTIÓN DE CONVOCATORIAS

En este módulo se compone de las siguientes entidades de la base de datos: convocatoria, base de

convocatoria, formato, archivo, solicitud, parámetros grupo, parámetros detalle, cronogramas,

actividad, tipo de proyecto, proyecto, en este módulo la dirección de investigación realiza la gestión

para establecer las bases de las convocatoria para los proyectos de investigación, cada base de

convocatoria permite adjuntar formatos los cuales son subidos al sistema y almacenador en el

servidor web en formato Pdf o Word, de igual forma permite administrar las actividades y establecer

los diferentes documentos que se deben entregar en cada actividad.

Cuando una convocatoria es definida por cada Unidad Académica, los investigadores en este

caso profesores y estudiantes realizan la presentación de proyectos, los cuales son subidos al sistema

bajo parámetros establecidos por la Dirección de Investigación y luego evaluados, con el fin de

determinar si un proyecto está bien establecido y apoya con el desarrollo de la comunidad y

formación académica del investigador, en la figura 53, se observa la comunicación entre

componentes para establecer una convocatoria.

5.1.6. MODULO GESTIÓN UNIVERSITARIA

Este módulo se compone de las siguientes entidades de la base de datos, escuelas esta entidad

hace referencia a unidades académicas, carreras hace referencias a las facultades, líneas de

investigación, sub líneas de investigación.

El sistema está diseñado para gestionar y soporta los proyectos de investigación de toda la

Universidad Católica de Cuenca, por lo cual debe permitir controlar las diferentes Unidades

Académicas y sus Facultades, de igual forma es importante establecer las líneas de investigación que

van a ser implementadas para la creación de las bases de convocatoria y establecer las sub líneas de

investigación que puede tener cada línea de investigación y asignarlas a las diferentes Facultades,

este módulo destaca su importancia en establecer las bases que los investigadores deben

- 94 -

implementar para realizar un proceso investigado en línea de las áreas de desarrollo del país, en la

figura 54, se observa la comunicación de los componentes en este módulo.

Fig. 53 Componentes Módulo Gestión Convocatorias

Fig. 54 Componentes Módulo Gestión Universitaria

5.1.7. MODULO GESTIÓN DE PROYECTOS

Este módulo es uno de los más complejos ya que se compone por la mayoría de entidades de la

base de datos estas son: convocatorias, proyecto, tipos de investigación, niveles de investigación,

solicitudes, escuelas (Unidades Académicas), carreras (Facultades), personas, objetivos,

documentos, aprobación y ajustes.

El sistema está diseñado para soportar y gestionar todos los proyectos de investigación que

existen y existirán en cada una de las Unidades Académicas de la Universidad Católica de Cuenca,

por lo cual debe permitir gestionar todo tipo de proyectos y a su vez cada uno de los módulos que

existe tal como la creación del proyecto, especificación de objetivos, ingreso de integrantes,

gestionar debidamente la aprobación de los mismos y la gestión de los ajustes a los proyectos que no

cumplen con los requisitos básicos, así también internamente en los diferentes módulos hacen

referencia a otros mantenimientos como la gestión de escuelas, carreras, convocatorias, gestión de

- 95 -

solicitudes y la asignación de líneas y niveles de investigación, en la figura 55, se observa la

comunicación que existe entre los diferentes componentes del módulo.

Fig. 55 Componentes Módulo de Proyectos

5.2. PROCESO DE INSTALACIÓN

5.2.1. INSTALACIÓN DE JDK

En primera instancia se debe instalar el JDK java, el cual es un complemento necesario y

primordial para la instalación de las demás herramientas que se utilizará con la finalidad de

desarrollar la aplicación de software.

Para instalar el complemento JDK, se debe descargar el instalador desde la página

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html, una vez

descargado, se accede a la carpeta de descarga en el cual se ejecutará como administrador y se

procede a realizar los siguientes pasos:

- 96 -

Fig. 56 Instalación de JDK - Ejecutando el instalador

Fig. 57 Instalación de JDK - Pantalla Inicial

Fig. 58 Instalación de JDK - Selección de Herramientas

- 97 -

Fig. 59 Instalación de JDK - Proceso de Instalación

Fig. 60 Instalación de JDK - Instalación Finalizada

Para comprobar si la instalación del complemento JDK fue exitoso se debe ejecutar el comando

java -version en una ventana de comandos, la cual se accede presionando las teclas Windows + R, se

ingresa el comando cmd y se presiona enter, una vez en la ventana de comandos ingresamos el

comando antes indicado como muestra la figura 60.

Fig. 61 Verificación del JDK

- 98 -

5.2.2. INSTALACIÓN DE NETBEANS

Una de las herramientas fundamentales para el desarrollo del software, es la plataforma en la cual

se desarrollará el código fuente del sistema, para instalar el IDE Netbeans 7.3.1, se deberá seguir los

siguientes pasos de instalación para realizar de una manera correcta y funcional.

Para instalar la plataforma de desarrollo, en la cual se va a codificar el sistema, se deberá

descargar el respectivo instalador desde la página https://netbeans.org/downloads/, una vez que se ha

descargado el instalador, se deberá dirigir a la carpeta de descarga en el cual se ejecuta como

administrador y se procede a realizar los siguientes pasos:

Fig. 62 Instalación Netbeans - Ejecución del Instalador

Fig. 63 Instalación Netbeans - Inicio de Instalación

Es fundamental aceptar los términos y condiciones que presenta el wizard de instalación de la

herramienta de desarrollo, ya que si no se confirma esta acción, el agente de instalación no permite

continuar con el proceso de instalación.

- 99 -

Fig. 64 Instalación Netbeans - Términos y Condiciones

En el proceso anterior en el cual se indica la instalación del JDK, se menciona que es un

complemento muy importante el cual facilitará la instalación de las herramientas seleccionadas para

el desarrollo de software, en este caso el JDK es necesario para continuar con la instalación del IDE

Netbeans..

Fig. 65 Instalación Netbeans - Selección de Complementos

- 100 -

Fig. 66 Instalación Netbeans - Proceso de Instalación

Fig. 67 Instalación Netbeans - Instalación Finalizada

5.2.3. INSTALACIÓN DEL SERVIDOR WEB TOMCAT

Con Tomcat se puede levantar un servidor web, que permitirá dar acceso adecuado a aplicaciones

de este tipo, para implementar un servidor web que trabaje con aplicaciones desarrolladas en

lenguaje java tenemos que seleccionar el que más se adapte a nuestros requerimientos, en este caso

hemos seleccionado el servidor Tomcat 7.

Primero se tiene que descargar el servidor Tomcat 7, de la página web

http://tomcat.apache.org/download-70.cgi, una vez realizada la descarga se continuará con la

ejecución realizando los siguientes pasos:

En la pantalla en el cual se configura los puertos se especificará según muestra la figura 71.

- 101 -

Fig. 68 Instalación Tomcat - Inicio de Instalación

Fig. 69 Instalación Tomcat - Términos y Condiciones

- 102 -

Fig. 70 Instalación Tomcat - Selección de Complementos

Fig. 71 Instalación Tomcat - Configuración de Puertos

- 103 -

Fig. 72 Instalación Tomcat - Ubicación del JRE 7

Fig. 73 Instalación Tomcat - Ubicación del Servidor Tomcat

- 104 -

Fig. 74 Instalación Tomcat - Iniciamos el Servidor

Después de instalar el servidor Tomcat 7, se tendrá que generar un archivo .war, el cual permitirá

generar lo necesario para que la aplicación funcione correctamente, para realizar esto se accede a

netbeans, se deberá seleccionar el proyecto y dar clic derecho sobre este, desplegando un menú,

donde se escogerá la opción Properties, desplegando otra ventana como se observa en la figura 75.

En la ventana de propiedades se da clic en build, visualizando tres opciones, se deberá escoger la

opción de packagingy como se observa en la figura 75, se selecciona la opción “Compress WAR

File” y luego se dará clic en ok, ahora solo queda generar el archivo .war para esto se da

nuevamente clic derecho en el proyecto y se tendrá que seleccionar la opción Limpiar y Construir

“Clean and Build” y esperar a que el proyecto se compile y se genere el archivo war, una vez

realizado esta proceso se debe dirigir a la carpeta donde se tiene el proyecto web guardado y

buscar la carpeta llamada Dist, en esta carpeta se almacena el archivo.

Como se observa en la figura 76, se debe inicializar el servidor tomcat, lo cual se realizará

mediante una terminal cmd, para esto se debe dar clic en el botón inicio y seleccionar la opción

ejecutar o a su vez presionar la tecla inicio + R, e ingresar el comando cmd, presionar Enter, al abrir

la terminal se escribirá el comando startup.bat y dar Enter [22] y listo se tendrá el servidor

levantado.

- 105 -

Fig. 75 Comprensión de la Aplicación

Fig. 76 Iniciar Servicio Tomcat [22]

- 106 -

5.2.4. INSTALACIÓN DEL SERVIDOR DE BASE DE DATOS

Para instalar el motor de la base de datos PostgreSQL se deberá descargar el instalador desde la

página oficial http://www.postgresql.org/download/windows/, una vez descargado se procederá a

realizar los siguientes pasos:

En primer lugar se accede a la carpeta donde se haya descargado el instalador y se lo ejecuta

como administrador como indica la figura 77, al inicializar se visualizará un wizard en el cual se

debe escoger la carpeta donde se instalará la base de datos, al continuar con la guía de instalación

propia del PostgreSQL, se llega a una instancia importante en la cual se especificará la contraseña

del administrador del gestor de la base de datos, en este paso se debe tener mucho cuidado e

ingresar una contraseña que recordará con facilidad, ya que esta contraseña servirá para configurar el

archivo persistence.xml de la carpeta Configuration Files del proyecto en Netbeans y configurar la

conexión con el gestor de reportes Ireport, por lo general se recomienda especificar la contraseña

admin [21], como lo indica la figura 80.

Fig. 77 Instalación PostgreSQL - Ejecución de instalador

Fig. 78 Instalación PostgreSQL - Instalación de Componentes

- 107 -

Fig. 79 Instalación PostgreSQL - Ubicación de la Base de Datos

Fig. 80 Instalación PostgreSQL - Contraseña PostgreSQL

Es importante especificar el puerto por el cual PostgreSQL realizará las debidas comunicaciones

con Netbeans por lo que se debe dejar el puerto por defecto que presenta el wizard de instalación

[21].

- 108 -

Fig. 81 Instalación PostgreSQL - Puerto PostgreSQL

Por últimos pedirá especificar la configuración regional, por lo general se selecciona la que está

por defecto siendo este el penúltimo paso, ya que después de este comenzará el proceso de

instalación.

Fig. 82 Instalación PostgreSQL - Configuración Regional

- 109 -

Fig. 83 Instalación PostgreSQL - Proceso de Instalación

Al finalizar la instalación quitamos la selección por defecto que muestra la pantalla final de

instalación, presionar terminar, como se observar la figura 84.

Fig. 84 Instalación PostgreSQL - Fin de Instalación

Luego de terminar con el proceso de instalación, solo falta ingresar a la aplicación de

PostgreSQL y cargar la base de datos.

5.2.5. CONFIGURACIÓN DE BASE DE DATOS

Para finalizar la instalación de todos los componentes que se utilizará para el desarrollo de la

aplicación, es crear la base de datos la cual interactuara con el IDE Netbeans, para realizar esta

acción se deberá seguir los siguientes pasos:

Acceder al gestor de base de datos PostgreSQL como indica la figura 85, para conectarse al

gestor se debe ingresar la contraseña que se especifica en la figura 80.

- 110 -

Fig. 85 Configuración Base Datos - Ingreso de Password

Una vez logeados en el gestor de base de datos, se deberá crear una base de datos, para realizar

esto se dará clic derecho sobre Database y seleccionar New Database, después ingresar los datos que

identifiquen a la base de datos tal como indica la figura 87.

Fig. 86 Configuración Base Datos - Crear Base de Datos

- 111 -

Fig. 87 Configuración Base Datos - Credenciales de Base de Datos

Al confirmar la información de identificación y creación de la base de datos, se visualizará una

pantalla semejante a la figura 88.

Fig. 88 Configuración Base Datos - Creación Finalizada

Si no se desea crear la base de datos de manera gráfica mediante el wizard de creación, se podrá

ejecutar el siguiente código, el cual genera la base de datos con las especificaciones ingresadas en la

figura 87, para realizar esto se debe abrir una ventana de comandos, la cual se obtiene seleccionando

la base de datos por defecto llamada postgres y dar clic en el icono SQL de la barra de herramientas,

tal como indica la figura 89.

- 112 -

Fig. 89 Configuración Base Datos - Ventana de Comandos

En la ventana de comandos que se generó ingresar los siguientes comandos:

DROP DATABASE dbinvestigacion;

CREATE DATABASE dbinvestigacion

WITH OWNER = postgres

ENCODING = 'UTF8'

TABLESPACE = pg_default

LC_COLLATE = 'Spanish_Ecuador.1252'

LC_CTYPE = 'Spanish_Ecuador.1252'

CONNECTION LIMIT = -1;

5.2.6. INSTALACIÓN DE IREPORTS

Para instalar el programa Ireports con el cual se creará los reportes a utilizar se lo descarga de la

página del proveedor https://community.jaspersoft.com/project/ireport-designer, una vez culminada

la descarga, acceder a la carpeta donde se ejecutará el instalador como Administrador, para esto dar

clic derecho como indica la figura 90.

Es importante especificar la versión de Ireports que se utilizará para generar perfectamente los

reportes, se utilizará la versión 3.0.

Una vez ejecutado el instalador, el software de instalación muestra el wizard en el cual se

especificará los parámetros de instalación.

Fig. 90 Instalación Ireports – Ejecución

- 113 -

Fig. 91 Instalación Ireport – Inicio

Fig. 92 Instalación Ireports - Términos y Condiciones

Al aceptar los términos, se debe indicar las características del software que se instalará, para tener

un software completo que brinde todos los complementos tal como indica la figura 93.

- 114 -

Fig. 93 Instalación Ireports – Características

Antes de especificar la carpeta de destino, en la cual se instalará por completo el sistema Ireports,

se debe tener en cuenta que por defecto carga la dirección C://Program Files/, si se realiza la

instalación en aquel path se tendrá problemas al configurar la conexión a la base de datos ya que se

necesitan todos los permisos de administración, para evitar estos inconvenientes es indispensable

instalar en cualquier otra dirección.

Fig. 94 Instalación Ireports – Dirección

- 115 -

Fig. 95 Instalación Ireports – Identificación

Fig. 96 Instalación Ireports – Proceso

Al finalizar el proceso de instalación el wizard indicará que se ha instalado correctamente y

ejecutará el software automáticamente, para esto se da clic en Finish (figura 97), una vez realizado

esta acción se ejecutará el software Ireports el cual se observa en la figura 98.

- 116 -

Fig. 97 Instalación Ireports – Finalización

Fig. 98 Software Ireports

Una vez inicializado Ireports se debe configurar y agregar la librería necesaria para una conexión

perfecta con la base de datos utilizada para el desarrollo la cual es PostgreSQL, para esto acceder al

menú Options y dentro de este seleccionar Classpath.

Al ingresar a la ventana de Classpath se debe seleccionar el jar postgresql-9.4-1201.jdbc4.jar

necesario para la conexión de Ireports con PostgreSQL, para esto dar clic en el botón Add Jar,

seleccionar el archivo respectivo, una vez realizado esto la librería se cargará en la ventana de

Classpath, para finalizar dar clic en el botón Save Classpath, tal como indica la figura 99.

- 117 -

Fig. 99 Librería Postgresql – Ireports

Al agregar la librería, se puede realizar la debida configuración de conexión a la base de datos, se

dará clic en el icono de motor de base de datos, al dar clic en este muestra otra ventana donde se

debe seleccionar el driver Conexión Base Datos JDBC, para continuar dar clic en el botón Próximo.

Fig. 100 Driver Conexión PostgreSQL – Ireports

- 118 -

Para especificar las credenciales, identificadores y contraseñas de conexión el sistema Ireports

visualiza otra pantalla después de haber dado clic en el botón Próximo.

En la siguiente ventana se debe especificar el nombre de conexión, seleccionar el JDBC Driver el

cual debe ser org.postgresql.Driver, en la sección JDBC URL no se debe realizar ningún cambio ya

que esto se modifica automáticamente dando clic en el botón Wizard siempre y cuando se ingrese

todos los datos, se ingresará él Server Address que varía dependiendo en qué ambiente se tiene

instalado el motor de base de datos, si se trata de un servidor especificar la dirección IP y puerto,

pero si está en la misma PC de desarrollo especificar el localhost, en Database ingresar el nombre de

la base de datos que se creó en el gestor Postgres, lo más importante es especificar el User Name que

por lo general es postgres, lo que varía es el password el cual es la misma contraseña con la cual se

ingresa a PostgreSQL, al ingresar todos los datos se debe seleccionar el check Save Password y

luego clic en Wizard con el cual se modificará la dirección JDBC URL, para comprobar la conexión

dar clic en Test, si la prueba es satisfactoria dar clic en Save, tal como indica la figura 101.

Fig. 101 Credenciales Conexión PostgreSQl – Ireports

5.2.7. INSTALACIÓN DE IREPORTS EN NETBEANS

La instalación de Ireports en Netbeans facilita la creación de reportes directamente desde la

plataforma de desarrollo, para esto se debe instalar los plugins o complementos con los cuales se

modifica la interfaz del Netbeans, los plugins a utilizar es el 1349977296_iReport-4.7.1-plugin.

Para lograr esto se debe acceder a Netbeans, menú Tools y dentro de este escoger la opción

Plugins, tal como indica la figura 102.

- 119 -

Fig. 102 Netbeans Plugins

Una vez seleccionado la opción Plugins el sistema visualiza una nueva pantalla donde se

accederá a la pestaña Downloader, en la cual dar clic en el botón Add Plugins (figura 103), el cual

visualiza una ventana de exploración, donde se deberá seleccionar los Plugins que forman parte de

1349977296_iReport-4.7.1-plugin las mismas que se observa en la figura 104.

Fig. 103 Netbeans Agregar Plugins

Fig. 104 Plugins Ireport Netbeans

- 120 -

Al seleccionar los 4 Plugins damos clic en abrir, los cuales se cargarán en la pantalla principal de

la Ventana Plugins (figura 103), para instalar dar clic en el botón Install, una vez finalizada la

instalación se debe de reiniciar el Netbeans, al ingresar nuevamente se visualiza que Netbeans brinda

la facilidad de crear la conexión de Ireports tal como muestra la figura 105.

Fig. 105 Interfaz Netbeans – Ireports

Para configurar la conexión a la base de datos se sigue los pasos descritos en las figuras 100 y

101.

Para un correcto funcionamiento del Plugin Ireports en Netbeans se accede al menú Tools,

después seleccionar el submenú Ant Library, en el cual se busca la Librería jasperReport y se lo

elimina, como se indica en la figura 106.

Fig. 106 Eliminación Plugin Ireports

Al realizar la acción de la figura 106, se debe crear una nueva librería en la cual se asignará

únicamente los .jar necesarios, para esto acceder al menú Tools, submenú Ant Library, en la nueva

ventana dar clic en New Library, la cual visualiza un pop up donde se ingresará el nombre de la

nueva librería como muestra la figura 107.

- 121 -

Fig. 107 Crear Librería Netbeans

Ahora debemos asignar los .jar a la nueva librería creada, para esto ingresar nuevamente al menú

Tools-Ant library, seleccionar la nueva librería y dar clic en Add JAR/Folder, al seleccionar este

muestra una ventana de exploración en la cual se deberá seleccionar los .jar, para esto se debe

descargar la librería jasperreports-4.7.1-project, la cual contiene los jar que se detallan en la figura

108, las mismas que se encuentran en las carpetas dist y lib.

Fig. 108 Jars a Cargar Netbeans

Se debe asignar la nueva librería creada en el proyecto de Netbeans, para esto se da clic derecho

en el package Libreries, seleccionar la opción Add Library (figura 109), se visualiza otro ventana

donde se debe dar clic en el botón Import, una vez realizado esto seleccionar la librería creada en

la cual se asignaron los .jar indicados anteriormente y dar clic en Import (figura 110).

Fig. 109 Agregar Nueva Librería Netbeans

- 122 -

Fig. 110 Importar Librería Netbeans

Fig. 111 Seleccionar Nueva Librería

Para comprobar que la librería se haya importado correctamente se accede al package Libraries,

en el cual deben estar asignados todos los .jar (figura 108) del proyecto web, tal como indica la

figura 112.

- 123 -

Fig. 112 Librerias Importadas Netbeans

5.3. PRUEBAS

Las pruebas se realizan sobre los casos de uso propuestos, para definir si cada proceso que se

debe realizar está funcionando correctamente, los casos de uso a evaluar son los siguientes,

Administración del sistema, Gestión de carreras y escuelas, Gestión de convocatorias de proyectos,

Gestión de tipos y niveles de investigación, Gestión de formatos, Gestión de parámetros y Gestión

de proyectos.

Las pruebas se realizaron a medida que se iba desarrollando cada módulo, y los resultados se

especifican de la tabla 20 a la 25, para realizar pruebas más detalladas se debe realizar la

implantación en la Universidad Católica de Cuenca, y observar el comportamiento del sistema.

TABLA XX PRUEBAS ADMINISTRACIÓN DEL SISTEMA

ID caso de prueba PRUEBA 001

Nombre caso de prueba Administración del sistema.

Descripción Se probara el acceso al sistema y control de permisos a las

diferentes opciones a las que un usuario tendrá acceso.

- 124 -

Precondiciones El usuario debe estar registrado en el sistema y pertenecer a un

grupo de trabajo.

Pasos y condiciones ejecución Para acceder al sistema y poder gestionar campos de administración,

es importante solicitar un usuario con estas características, caso contrario

si solo se desea acceder a las opciones básicas del sistemas, se debe

registrar el usuario a través del formulario de registro, una vez con un

usuario se accede al sistema y se verifica las opciones a las que se tiene

acceso, revisando los diferentes permisos que se tienen, entre los

permisos posibles están crear, eliminar, modificar, listar, imprimir, una

vez comprobado las opciones del sistema el usuario debe cerrar la sesión

de usuario.

Resultado esperado Tener acceso solo a los permisos establecidos.

Crear usuarios y registrarse.

Controlar la sesión del usuario.

Estado caso de prueba •Ejecutado Exitoso

Resultado obtenido El usuario tiene acceso solo a los establecidos por el

administrador del sitio, se dan problemas con la sesión al

momento de cerrarla, y los usuarios se crean correctamente.

TABLA XXI PRUEBA GESTIÓN DE CARRERAS Y ESCUELA

ID caso de prueba PRUEBA 002

Nombre caso de prueba Gestión de carreras y escuelas

Descripción Se deben crear y gestionar las facultades “carreras” y las

unidades académicas “escuelas”.

Precondiciones Para crear una carrera se debe crear primero una escuela.

Pasos y condiciones ejecución EL administrador del sitio debe acceder con usuario que cuente con

privilegios para gestionar las escuelas y carreras, luego de esto debe crear

una escuela indicando los datos básicos para su funcionamiento, una vez

creado puede realizar actualizaciones si lo requiere, luego puede proceder

a crear las carreras e identificar la escuela a la que pertenece cada carrera.

Resultado esperado Creación y gestión de Escuela.

Creación y gestión de carreras por escuela.

Estado caso de prueba •Ejecutado Exitoso

Resultado obtenido El usuario crea exitosamente las escuelas y carreras.

TABLA XXII PRUEBA GESTIÓN DE CONVOCATORIAS

ID caso de prueba PRUEBA 003

Nombre caso de prueba Gestión de convocatorias

Descripción Se debe permitir crear las convocatorias de proyectos,

estableciendo los requerimientos y procedimientos necesarios para

poder inscribirse en una convocatoria.

- 125 -

Precondiciones La dirección de investigación se encarga de establecer las bases

de cada convocatoria y cada unidad académica se encarga de crear en

si la convocatoria y establecer las fechas para cada actividad.

Pasos y condiciones ejecución Primero que nada la dirección de investigación debe establecer

las solicitudes que se van a pedir a cada proyecto que participe en la

convocatoria, entre estas solicitudes están: protocolo de

investigación, artículos, papers, avances de cada proyecto entre otros,

una vez establecidas las solicitudes se debe crear la base de la

convocatoria y asignarle esta solicitudes, una vez definida la base de

convocatoria, cada unidad académica puede crear la convocatoria en

sí, definiendo en las fechas que se deben realizar y las actividades

que la compondrán.

Resultado esperado Creación de bases de convocatorias.

Creación de convocatorias y cronograma de actividades.

Estado caso de prueba •Ejecutado Exitoso

Resultado obtenido Se puede crear correctamente las convocatorias y enlazarlas

correctamente con un cronograma de actividades y una base de

convocatoria.

TABLA XXIII PRUEBA GESTIÓN TIPOS DE INVESTIGACIÓN

ID caso de prueba PRUEBA 004

Nombre caso de prueba Gestión de tipos de investigación

Descripción Se debe permitir gestionar los tipos de investigación que van

ser parte lo proyectos investigativos, estableciendo los

requerimientos y procedimientos que contemplen a todas las áreas

de investigación de la Universidad Católica de Cuenca.

Precondiciones La dirección de investigación se encarga de establecer los tipos

de investigación que existirán en el sistema.

Pasos y condiciones ejecución Primero que nada la dirección de investigación debe establecer

los tipos de investigación que se va a escoger al momento de la

creación de un proyecto por parte de los investigadores. La gestión

de los tipos de investigación nos debe facilitar realizar las acciones

de crear, modificar, eliminar, ver y de activar y desactivar un tipo de

investigación.

Resultado esperado Gestión de tipos de investigación.

Estado caso de prueba Ejecutado Exitoso

Resultado obtenido Se puede crear correctamente los diferentes tipos de

investigación los cuales han sido previamente analizados por la

dirección de investigación.

TABLA XXIV PRUEBA GESTIÓN NIVELES DE INVESTIGACIÓN

ID caso de prueba PRUEBA 005

Nombre caso de prueba Gestión de niveles de investigación

- 126 -

Descripción Se debe permitir gestionar los niveles de investigación que van

ser parte lo proyectos investigativos, estableciendo los adecuados

para que cubran cada uno de los requerimientos y diversidad de

niveles que existen en todas las áreas de investigación de la

Universidad Católica de Cuenca.

Precondiciones La dirección de investigación se encarga de establecer los niveles

de investigación que existirán en el sistema.

Pasos y condiciones ejecución Primero que nada la dirección de investigación debe establecer

los niveles de investigación que se va a escoger al momento de la

creación de un proyecto por parte de los investigadores. La gestión

de los niveles de investigación nos debe facilitar realizar las acciones

de crear, modificar, eliminar, ver y de activar y desactivar un nivel de

investigación.

Resultado esperado Gestión de niveles de investigación.

Estado caso de prueba Ejecutado Exitoso

Resultado obtenido Se puede crear correctamente los diferentes niveles de

investigación los cuales han sido previamente analizados por la

dirección de investigación.

TABLA XXV PRUEBA GESTIÓN DE PROYECTOS

ID caso de prueba PRUEBA 008

Nombre caso de prueba Gestión de proyectos

Descripción Se debe permitir crear y gestionar el ingreso de los datos que

forman parte de un proyecto, así mismo realizar la aprobación e

ingresar los ajustes.

Precondiciones Deben existir creados las convocatorias, solicitudes, nivel y tipo

de investigación, tipos de documento y los usuarios deben estar

registrados para formar parte del proyecto como integrante.

Pasos y condiciones ejecución El usuario investigador es el encargado de ingresar los datos

básicos de un proyecto, en el cual especificará la convocatoria, nivel

y tipo de investigación y seleccionar la solicitud a la cual va a

aplicar, así mismo ingresar todos los datos obligatorios.

EL usuario puede gestionar en el siguiente modulo los objetos los

objetivos que se definen para el proyecto siendo estos Objetivos

Específicos, Objetivo General y Objetivo de Fin, cada uno con sus

objetivos de jerarquía, línea, definición, fuentes y supuestos.

El investigador al acceder al siguiente modulo tendrá que

especificar el documento digital que se deberá ingresar como

comprobación de la información ingresa.

El usuario deberá administrar los integrantes del proyecto, siendo

estos los usuarios registrados en el sistema.

Los usuarios Comité y Dirección de investigación deberán

acceder a los módulos de aprobación y ajustes para realizar la

respectiva gestión a los proyectos.

- 127 -

Resultado esperado Administración total de ingreso de proyecto.

Ingreso, modificación, eliminación de objetivos.

Carga del archivo digital.

Gestión de integrantes.

Aprobación de proyectos.

Administración y gestión de ajustes.

Estado caso de prueba •Ejecutado Exitoso

Resultado obtenido El usuario crea exitosamente los proyectos, objetivos, carga

del archivo digital y especificación de integrantes y usuarios

Comité y dirección de investigación aprueban y asignar ajustes a

los proyectos.

- 128 -

CONCLUSIONES

Las especificaciones de la ley de educación superior son bases establecidas y sirven de

referencia para el desarrollo de proyectos informáticos que apoyen al mejoramiento de la

productividad, innovación, creación y creatividad de docentes y estudiantes.

Para definir los objetivos de un proyecto es importante conocer las necesidades,

requerimientos, resultados y objetivos que deberá satisfacer el sistema, para esto hay que

realizar procesos de investigación y analizar detenidamente los diferentes documentos que

faciliten la etapa inicial de un proyecto.

Para desarrollar sistemas informáticos es fundamental realizar un correcto y profundo

análisis de cómo va a funcionar el sistema, por lo cual el estándar RUP (Proceso Unificado

Racional) incluye etapas importantes para la creación de software el cual contempla desde la

etapa principal del ciclo de vida del desarrollo de software que es el análisis hasta llegar a la

implantación.

El desarrollo de las aplicaciones puede ser complicado, sobre todo al momento de programar,

por lo cual definir una arquitectura de desarrollo es primordial, ya que brinda escalabilidad,

soporte, fácil entendimiento de código y algo muy importante reutilización de código fuente.

Para desarrollar aplicaciones web es importante establecer estándares de calidad que

permitan brindar un buen servicio a los usuarios, por lo cual es importante el uso de

frameworks y estándares ya establecidos, que faciliten el desarrollo de estas aplicaciones con

la finalidad de dedicar más tiempo al análisis del sistema, el cual es la base fundamental para

que el desarrollo del software sea estructurado disminuyendo tiempo invertido en la creación

de código fuente.

- 129 -

RECOMENDACIONES

Se recomienda tener en cuenta software de gestión de proyectos tipo PMBok (Project

Management Body of Knowledge – Gestión de Proyectos del Conocimiento) desarrollado por PMI

(Project Management Institute), para identificar su estructura base con la finalidad de implementar

estos fundamentos en la aplicación.

Definir con anticipación la estructura, herramientas y tecnología a implementar en el sistema, con

la finalidad de enfocar todos los recursos al desarrollo de software.

Se recomienda poseer un servidor FTP, donde se almacenará una réplica de todos los documentos

ingresados en la plataforma informática, con la finalidad de poseer un respaldo actualizado ya que se

creará una copia al instante de cargar el documento al sistema.

Se recomienda instalar y ejecutar el software desde un servidor de aplicaciones que contenga los

recursos de hardware necesarios para un funcionamiento eficaz y eficiente, con lo cual permite

aprovechar al máximo la aplicación web y todos sus componentes.

- 130 -

BIBLIOGRAFÍA

[1] J. R. Aguirre, «Estado del Arte de la Formación Profesional en Seguridad Informatica: Estrategias y

tendencias,» Bogota - Colombia, Universidad Politécnica de Madrid, 2004, p. 28.

[2] I. Sommerville, Ingenieria de Software, Mexico, 2011.

[3] R. S. Pressman, Ingenieria de Software - Un Enfoque Practico 5ta Edición, Madrid: Concepción

Fernandez Madrid, 2002.

[4] M. Cuazilt, «Sliderhare,» Sliderhare, 2011. [En línea]. Available:

http://es.slideshared.net/manuelit17/tipos-de-usuario.

[5] IBM, «Tivoli,» IBM, [En línea]. Available: http://www.ibm.com/software/es/tivoli/security/.

[6] CITRIX, «CITRIX,» Citrix Systems, Inc, 2013. [En línea]. Available: http://lac.citrix.com/.

[7] J. Castillo, «Requerimientos no funcionales y arquitectura de software».

[8] D. O. Santander, «Auditoria Sistemas UCB,» [En línea]. Available:

http://auditoriasistemasucb.pbworks.com/requisitos+minimos+de+seguridad.pptx.

[9] A. Prieto y M. Martínez, «Sistemas de información en las organizaciones: Una alternativa para

mejorar la productividad gerencial en las,» Revista de Ciencias Sociales (Ve), vol. X, nº 2, pp. 322 -

337, 2004.

[10] Wikpedia, «Wikipedia,» [En línea]. Available:

http://es.wikipedia.org/wiki/Seguridad_inform%C3%A1tica#T.C3.A9cnicas_para_asegurar_el_sistema.

[11] J. A. M. Torres, «Gulag,» 5 Febrero 2009. [En línea]. Available: www.gulag.org.mx/juntas/2009-

02-21-seguridad-informatica-gndx-tono-zk/seguridad-informatica.pdf.

[12] S. Zamenfel, «Brainlabs Newa IT,» 17 09 2011. [En línea]. Available:

http://www.brainlabs.com.ar/novedad/seguridad/politicas-de-seguridad-2/.

[13] America, «AMERICA LEARNING & MEDIA,» ALM, [En línea]. Available:

http://www.americalearningmedia.com/edicion-005/61-analisis/248-consideraciones-antes-de-

seleccionar-soluciones-tecnologicas. [Último acceso: 2010].

[14] ORACLE, «ORACLE,» [En línea]. Available: http://www.java.com/es/download/whatis_java.jsp.

[15] H. Espinoza, «Open Word,» 2055. [En línea]. Available:

http://www.lgs.com.ve/pres/PresentacionES_PSQL.pdf.

[16] J. E. Gonzáles Cornejo, «Arquitectura en Capas DNA,» DocIRS, 25 Marzo 2001. [En línea].

Available: http://www.docirs.cl/arquitectura_tres_capas.htm.

[17] Y. Martínez Díaz, «Monografias,» [En línea]. Available:

http://www.monografias.com/trabajos98/tecnologias-y-herramientas-desarrollo-aplicaciones-web-

java/tecnologias-y-herramientas-desarrollo-aplicaciones-web-java.shtml.

- 131 -

[18] «METODOLOGÍA PARA EL DESARROLLO DE UN SISTEMA DE INTELIGENCIA DE

NEGOCIOS BASADA EN EL PROCESO UNIFICADO».

[19] J. Pavón Mestras, «El patrón Modelo-Vista-Controlador (MVC),» Madrid.

[20] L. Inf, «http://www.lab.inf.uc3m.es/~a0080802/RAI/mvc.html,» 2013. [En línea].

[21] C. R. Estrada Once, Desarrollador de Software Libre y Propietario.

[22] E. Weiss, «Eder Weiss's Blog,» 11 05 2013. [En línea]. Available:

http://webxico.blogspot.com/2013/05/instalancion-y-configuracion-manual-de.html.

[23] REPÚBLICA DEL ECUADOR, «LEY ORGÁNICA DE EDUCACIÓN SUPERIOR,» EDITORA

NACIONAL DEL ECUADOR, QUITO, 2010.

- 132 -

ANEXO 1