PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO
Dirección Académica - Escuela de Sistemas
DESARROLLO E IMPLEMENTACIÓN DE UNA APLICACIÓN WEB PARA LA ADMINISTRACIÓN DE DISERTACIONES DE GRADO EN LA PUCE SD
Disertación de Grado Previa la obtención del título de Ingenieros de Sistemas y Computación Línea de Investigación: Estudio, Diseño e Implementación de Software
Autores: JULIO CÉSAR RUIZ PÁRRAGA PAÚL VINICIO VACA AVILÉS Director: MG. RODOLFO SIRILO CÓRDOVA GÁLVEZ
SANTO DOMINGO - ECUADOR Febrero, 2015
PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO
Dirección Académica - Escuela de Sistemas HOJA DE APROBACIÓN DESARROLLO E IMPLEMENTACIÓN DE UNA APLICACIÓN WEB PARA LA ADMINISTRACIÓN DE DISERTACIONES DE GRADO EN LA PUCE SD Línea de Investigación: Estudio, Diseño e Implementación de Software Autores: JULIO CÉSAR RUIZ PÁRRAGA PAÚL VINICIO VACA AVILÉS
Rodolfo Sirilo Córdova Gálvez, Mg. DIRECTOR DE LA DISERTACIÓN DE GRADO Ángel Ramiro Hurtado Hurtado, Ing. CALIFICADOR Adrian Rolando Cevallos Dueñas, Mg. CALIFICADOR Rodolfo Sirilo Córdova Gálvez, Mg. DIRECTOR DE LA ESCUELA DE SISTEMAS
SANTO DOMINGO - ECUADOR Febrero, 2015
iii
DECLARACIÓN DE AUTENTICIDAD Nosotros, Julio César Ruiz Párraga portador de la cedula de ciudadanía No. 172083790-3 y Paúl Vinicio Vaca Avilés portador de la cedula de ciudadanía No.171764363-7,
declaramos
que
los
resultados
obtenidos
en
la
investigación presentada como informe final, previo a la obtención del Grado de Ingeniero en Sistemas son absolutamente originales, auténticos y personales. En tal virtud, declaramos que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de nuestra exclusiva responsabilidad legal y académica.
Julio César Ruiz Párraga CI. 172083790-3
Paúl Vinicio Vaca Avilés CI. 171764363-7
iv
AGRADECIMIENTOS Un agradecimiento especial a todos los profesionales que laboran en la Pontificia Universidad Católica del Ecuador Sede Santo Domingo, por brindarnos el apoyo requerido en el momento de recopilación de información, también a los Directores de Escuela por facilitarnos los requerimientos para hacer posible el desarrollo del proyecto,
a nuestro
Director de Disertación por encaminarnos en todas las fases de desarrollo de este trabajo final.
Los Autores
v
DEDICATORIA
Este proyecto va dedicado a mi familia; a mis padres Guadalupe y Salomón, que siempre impulsaron mi preparación y superación tanto en lo humano como en lo profesional, a mis hermanos Eduardo y Cinthya por el constante apoyo, cariño y confianza que depositaron en mí.
Julio Ruiz
Tengo el honor en ésta ocasión de dedicar el trabajo de una parte importante de mi vida a mis padres quienes forjaron los pilares de educación, moral y el ímpetu para seguir siempre adelante. Pero en especial, gracias a ti madre querida; he logrado culminar una de mis metas, humildemente reconozco todo el apoyo que me has brindado y tengo hoy el orgullo de poder decir que sin ti no hubiese logrado ser la persona que redacta éstas palabras en éste momento.
Paúl Vaca
vi
RESUMEN El presente proyecto tuvo como finalidad desarrollar e implementar una aplicación web denominada SADG (Sistema de Administración de Disertaciones de Grado), en la Pontificia Universidad Católica del Ecuador sede Santo Domingo; el cual permite el manejo de información referente a disertaciones de grado en forma automática. A través de la intranet en la Universidad, los usuarios actualizan información, generan e imprimen reportes y gráficos estadísticos; los cuales facilitan el análisis y la interpretación de la información sobre los estudiantes y graduados, para sustentar la toma de decisiones. El sistema fue desarrollado en su totalidad con herramientas de Código Libre; para respaldar la
flexibilidad y
redistribución del mismo, lo que permite a la PUCE SD aplicar la innovación tecnológica en implementación de plataformas web, para administrar las disertaciones de grado. Se aplicó la metodología de programación extrema, debido a que se ajusta a las necesidades presentes en el problema de investigación, garantizando un desarrollo ágil y la calidad del sistema.
vii
ABSTRACT This project was aimed to develop and implement a web application called SADG (Sistema de Administraci贸n de Disertaciones de Grado), at the Pontificia Universidad Cat贸lica del Ecuador Sede Santo Domingo, which allows handling the information about dissertations automatically. Through the University's intranet, users update information, generate and print reports and statistical charts, which facilitate the analysis and interpretation of information about students and graduates, to support decision making. The system was developed entirely with Open Source tools to support the flexibility and redistribute it, enabling PUCE SD applying technological innovation in web platform implementation for the management of dissertations. The extreme programming methodology was implemented because it meets the current needs of the research problem, ensuring agile development and system quality.
viii
ÍNDICE DE CONTENIDOS
HOJA DE APROBACIÓN .......................................................................................................... ii DECLARACIÓN DE AUTENTICIDAD ..................................................................................... iii AGRADECIMIENTOS .............................................................................................................. iv DEDICATORIA ..........................................................................................................................v RESUMEN ............................................................................................................................... vi ABSTRACT ............................................................................................................................. vii ÍNDICE DE CONTENIDOS .................................................................................................... viii ÍNDICE DE FIGURAS ............................................................................................................ xiv ÍNDICE DE TABLAS .............................................................................................................. xvi ÍNDICE DE GRÁFICOS ....................................................................................................... xviii 1
INTRODUCCIÓN A LA DISERTACIÓN DE GRADO ...................................................... 1
2
PLANTEAMIENTO DEL PROBLEMA .............................................................................. 3
2.1
Antecedentes ............................................................................................................... 3
2.2
Problema de Investigación ........................................................................................... 5
2.3
Justificación .................................................................................................................. 6
2.4
Objetivos ...................................................................................................................... 7
2.4.1
Objetivo General ...................................................................................................... 7
2.4.2
Objetivos Específicos ............................................................................................... 7
3
MARCO REFERENCIAL .................................................................................................. 8
3.1 3.1.1
Revisión de la literatura o fundamentos teóricos ......................................................... 8 IDE Eclipse ............................................................................................................... 8
ix
3.1.2
IDE NetBeans........................................................................................................... 9
3.1.3
Base De Datos ....................................................................................................... 10
3.1.3.1
Sistema Gestor de Base de Datos ..................................................................... 11
3.1.3.2
Oracle Database ................................................................................................ 12
3.1.3.3
Oracle SQL Developer Data Modeler ................................................................ 13
3.1.4
PHP ........................................................................................................................ 14
3.1.4.1
OCI8 ................................................................................................................... 14
3.1.5
AJAX ...................................................................................................................... 15
3.1.6
XML ........................................................................................................................ 16
3.1.7
JAVASCRIPT ......................................................................................................... 16
3.1.7.1
JQuery ................................................................................................................ 18
3.1.8
DOM ....................................................................................................................... 18
3.1.9
MVC ....................................................................................................................... 19
3.1.10
CSS ........................................................................................................................ 20
3.1.11
Encriptaci贸n de datos ............................................................................................. 22
3.1.11.1
MD5 .................................................................................................................... 22
3.1.12
Highcharts .............................................................................................................. 23
3.1.13
Licencias de software ............................................................................................. 23
3.1.13.1
Licencia GNU GPL ............................................................................................. 24
3.1.13.2
Licencia Creative Commons .............................................................................. 25
3.1.13.3
Licencias MIT ..................................................................................................... 26
3.1.14
Single Page Interface ............................................................................................. 26
3.1.15
Patr贸n Singleton ..................................................................................................... 27
3.2
Hip贸tesis de trabajo ................................................................................................... 28
x
3.2.1 4
Matriz operacional de las variables ........................................................................ 28
METODOLOGÍA DE LA INVESTIGACIÓN .................................................................... 30
4.1
Diseño / Tipo de investigación ................................................................................... 30
4.1.1
Investigación Descriptiva ....................................................................................... 30
4.1.2
Investigación Aplicada ........................................................................................... 30
4.1.3 Investigación de Campo .............................................................................................. 31 4.1.4
Método Deductivo .................................................................................................. 31
4.2
Población / Universo .................................................................................................. 31
4.3
Muestra ...................................................................................................................... 32
4.4
Instrumentos de recogida de datos ............................................................................ 33
4.4.1 Análisis Bibliográfico ..................................................................................................... 33 4.4.2
Observación ........................................................................................................... 34
4.4.3
Inducción ................................................................................................................ 34
4.4.4
Encuesta ................................................................................................................ 34
4.4.5
Entrevista ............................................................................................................... 35
4.4.6
Cuestionario ........................................................................................................... 35
4.5
Técnicas de análisis de datos .................................................................................... 36
4.5.1
Análisis Cuantitativo ............................................................................................... 36
4.5.2
Análisis Cualitativo ................................................................................................. 37
4.6
Metodología de desarrollo .......................................................................................... 37
4.6.1
Programación Extrema .......................................................................................... 37
4.6.1.1
ANÁLISIS ........................................................................................................... 38
4.6.1.1.1
Especificación de Requerimientos ..................................................................... 38
4.6.1.1.2
Historias De Usuario .......................................................................................... 39
xi
4.6.1.1.3
Planificación de entregas ................................................................................... 40
4.6.1.2
DISEÑO .............................................................................................................. 43
4.6.1.2.1
Diseño de la Base de Datos ............................................................................... 43
4.6.1.2.2
Diseño de las tarjetas CRC ................................................................................ 43
4.6.1.2.3
Diagrama de Clases ........................................................................................... 45
4.6.1.2.4
Diseño Arquitectónico ........................................................................................ 45
4.6.1.2.5
Diseño de Interfaces .......................................................................................... 45
4.6.1.2.6
Estructura jerárquica del Sistema ...................................................................... 46
4.6.1.3
IMPLEMENTACION Y CODIFICACIÓN ............................................................ 46
4.6.1.3.1
Implementación de las iteraciones ..................................................................... 46
4.6.1.3.2
Seguimiento de las Iteraciones .......................................................................... 47
4.6.1.4
PRUEBAS .......................................................................................................... 50
4.6.1.4.1
Pruebas de Aceptación ...................................................................................... 50
5
RESULTADOS ............................................................................................................... 52
5.1
Discusión y análisis de resultados. ............................................................................ 52
5.2
Análisis de requerimientos del SADG ........................................................................ 52
5.2.1
Entrevista aplicada a Directores de escuelas de la PUCE SD. ............................. 52
5.2.2
Entrevista aplicada en Dirección Académica de la PUCE SD. .............................. 53
5.2.3
Discusión de los resultados obtenidos en las entrevistas ..................................... 55
5.2.4
Encuesta dirigida a usuarios que participan en el proceso de administración de
disertaciones de grado de la PUCE SD. ................................................................................ 55 5.2.4.1
Introducción ........................................................................................................ 55
5.2.4.2
Determinación de la Población .......................................................................... 55
5.2.4.3
Tabulación de los datos ..................................................................................... 56
xii
5.2.4.4
Discusión de los resultados obtenidos en la Encuesta ...................................... 66
5.2.5
Identificación de Historias De Usuario ................................................................... 66
5.2.6
Plan de entregas .................................................................................................... 66
5.3
Diseño del Sistema de Administración de disertaciones de grado en base a los
requerimientos ....................................................................................................................... 68 5.3.1
Diseño Conceptual ................................................................................................. 68
5.3.2
Tarjetas CRC.......................................................................................................... 69
5.3.3
Diagrama de Clases SADG ................................................................................... 70
5.3.4
Diseño arquitectónico del SADG ........................................................................... 71
5.3.5
Diseño de Interfaces del SADG. ............................................................................ 72
5.3.5.1
Formulario de Ingreso al sistema ....................................................................... 72
5.3.5.2
Formulario Principal Secretarias ........................................................................ 72
5.3.5.3
Formulario Principal Directores .......................................................................... 74
5.3.6 5.4
Discusión de los resultados obtenidos en el diseño del SADG ............................. 74 Codificación e Implementación del SADG. ................................................................ 75
5.4.1
Codificación ............................................................................................................ 75
5.4.2
Implementación de Iteraciones .............................................................................. 80
5.4.3
Discusión de los resultados obtenidos en la codificación e implementación. ....... 80
5.5
Pruebas ...................................................................................................................... 81
5.5.1
Pruebas de Aceptación .......................................................................................... 81
5.5.2
Discusión de los resultados obtenidos en las pruebas .......................................... 82
CONCLUSIONES .................................................................................................................. 83 LÍMITES Y RECOMENDACIONES ....................................................................................... 85 REFERENCIAS ...................................................................................................................... 86
xiii
Referencias Bibliogrรกficas...................................................................................................... 86 Referencias Lincogrรกficas ...................................................................................................... 87 GLOSARIO............................................................................................................................. 88
xiv
ÍNDICE DE FIGURAS
Figura 1: Árbol del Problema en administración de disertaciones de la PUCE SD................. 4 Figura 2: Entorno Eclipse. ........................................................................................................ 9 Figura 3: Entorno NetBeans................................................................................................... 10 Figura 4: Oracle Database 11g .............................................................................................. 12 Figura 5: Entorno Oracle SQL Developer Data Modeler. ...................................................... 13 Figura 6: Logo php. ................................................................................................................ 14 Figura 7: Funcionamiento de AJAX ....................................................................................... 15 Figura 8: Logo JavaScript ...................................................................................................... 16 Figura 9: Estructura JavaScript .............................................................................................. 17 Figura 10: Una visión de la arquitectura de DOM .................................................................. 19 Figura 11: Diagrama del patrón de Arquitectura de Software MVC ...................................... 19 Figura 12: Componentes de un estilo CSS básico. ............................................................... 21 Figura 13: Logo Highcharts .................................................................................................... 23 Figura 14: Logo creative commons ........................................................................................ 25 Figura 15: Diagrama de Modelo de Objetos Patrón Singleton .............................................. 27 Figura 16: Estructura tarjetas CRC. ....................................................................................... 44 Figura 17: Estructura jerárquica del Sistema. ....................................................................... 46 Figura 18: Diseño de BDD de SADG. .................................................................................... 68 Figura 19: Diagrama de Clases del SADG. ........................................................................... 70 Figura 20: Diseño arquitectónico SADG. ............................................................................... 71 Figura 21: Ingreso al Sistema. ............................................................................................... 72
xv
Figura 22: Inicio Secretaria General. ..................................................................................... 73 Figura 23: Administración Estudiantes. ................................................................................. 73 Figura 24: Administración Temas de Disertación .................................................................. 74 Figura 25: Código de librerías y recursos externos. .............................................................. 75 Figura 26: Código de control de menú principal. ................................................................... 76 Figura 27: Código lista de alumnos. ...................................................................................... 77 Figura 28: Código resumen estadísticas Highcharts. ............................................................ 78 Figura 29: Código clase Login, Ingreso al Sistema. .............................................................. 79 Figura 30: Código diseño CSS. ............................................................................................. 79 Figura 31: Código patrón Singleton. ...................................................................................... 80
xvi
ÍNDICE DE TABLAS
Tabla 1: Tipos Licencias CC .................................................................................................. 26 Tabla 2: Matriz operacional de la variable Independiente. .................................................... 28 Tabla 3: Matriz operacional de la variable Dependiente. ....................................................... 29 Tabla 4: Participantes en el proceso de administración de disertaciones de grado.............. 33 Tabla 5: Tiempo Calendario ................................................................................................... 41 Tabla 6: Clasificación Clases del SADG. ............................................................................... 44 Tabla 7: Control de la Primera Iteración. ............................................................................... 48 Tabla 8: Control de la Segunda Iteración .............................................................................. 49 Tabla 9: Control de la Tercera Iteración. ............................................................................... 49 Tabla 10: Control de la Cuarta Iteración. ............................................................................... 49 Tabla 11: Formato Pruebas de Aceptación. .......................................................................... 50 Tabla 12: Tabulación de datos obtenidos en la pregunta 1. .................................................. 56 Tabla 13 : Tabulación de datos obtenidos en la pregunta 1.1. .............................................. 57 Tabla 14: Tabulación de datos obtenidos en la pregunta 2. .................................................. 58 Tabla 15: Tabulación de datos obtenidos en la pregunta 3. .................................................. 59 Tabla 16: Tabulación de datos obtenidos en la pregunta 4. .................................................. 60 Tabla 17: Tabulación de datos obtenidos en la pregunta 4.1. ............................................... 61 Tabla 18: Tabulación de datos obtenidos en la pregunta 4. .................................................. 62 Tabla 19: Tabulación de datos obtenidos en la pregunta 6. .................................................. 63 Tabla 20: Tabulación de datos obtenidos en la pregunta 6.1. ............................................... 64 Tabla 21: Tabulación de datos obtenidos en la pregunta 7. .................................................. 65
xvii
Tabla 22: Estimación de historias de usuario para el SADG. ................................................ 67 Tabla 23: Tarjeta CRC Controlador Estadística. ................................................................... 69 Tabla 24: Tarjeta CRC entidad Estadística. ........................................................................... 69 Tabla 25: Prueba de aceptación Generar reporte de disertaciones por tipo vinculación a la comunidad. ............................................................................................................................. 81 Tabla 26: Prueba de aceptación Autenticación de Usuarios. ................................................ 82
xviii
ÍNDICE DE GRÁFICOS
Gráfico 1: Representación porcentual de datos de la pregunta 1. ........................................ 57 Gráfico 2: Representación porcentual de datos de la pregunta 2. ........................................ 58 Gráfico 3: Representación porcentual de datos de la pregunta 3. ........................................ 60 Gráfico 4: Representación porcentual de datos de la pregunta 4. ........................................ 61 Gráfico 5: Representación porcentual de datos de la pregunta 5. ........................................ 62 Gráfico 6: Representación porcentual de datos de la pregunta 6. ........................................ 64 Gráfico 7: Representación porcentual de datos de la pregunta 7. ........................................ 65
1. INTRODUCCIÓN A LA DISERTACIÓN DE GRADO La tecnología informática es parte vital en toda empresa, para facilitar la ejecución de procesos en forma automática, con el fin de garantizar la agilidad, seguridad, organización y calidad en los servicios que brinda toda institución. Actualmente los programas se están orientando a la web, para mejorar el acceso a los usuarios que interactúan con el sistema, por ello es fundamental administrar de forma segura las transacciones e información que se procesa y potencializar el desarrollo de soluciones que brinden respuestas en tiempo real. El trabajo de esta disertación de grado consiste, en el desarrollo e implementación de una aplicación web para la administración de disertaciones de grado en la PUCE SD (Pontificia Universidad Católica del Ecuador Sede Santo Domingo), el mismo consta de tres secciones que detallan el proceso de desarrollo del proyecto y que se mencionan a continuación: La sección Preliminares contiene datos informativos sobre el proyecto, la institución donde se desarrolló, autores del proyecto, tutor de la disertación de grado, tribunal; su estructura está compuesta de la siguiente manera: Portada, hoja de aprobación, agradecimiento, dedicatoria, resumen, índice o tabla de contenidos, índice de figuras e índice de tablas. El Cuerpo es la parte central de la disertación escrita de grado, se especifica en si el proyecto que se elaboró con la disertación de grado, se incorporan conceptos teóricos, metodología de investigación y metodología de programación. Finalmente se emite el análisis y discusión sobre los resultados obtenidos. Esta sección consta de cinco capítulos: El Capítulo1 se refiere a la Introducción de la disertación de Grado, se explica el contenido de la disertación escrita de manera sinóptica con una breve descripción del proyecto. 1
2
El capítulo 2 realiza el Planteamiento del problema, se exponen los antecedentes de la investigación realizada, estos se basan en la delimitación del problema de estudio, los antecedentes se generan respondiendo a las preguntas básicas de investigación. Luego se justifica el trabajo realizado con
argumentos válidos, para concluir el capítulo se redacta el objetivo
general, y los objetivos específicos del proyecto. El Capítulo 3 trata del Marco referencial, aquí se redactan los fundamentos teóricos que se emplearon en la presente disertación para desarrollar la aplicación web. Los conceptos expuestos en este apartado son de propiedad y autoría exclusiva de los desarrolladores del proyecto. Se formula la hipótesis de trabajo con sus respectivas matrices de variables, que exponen los conceptos, definiciones e indicadores de medición. La Metodología de Investigación abarca el Capítulo 4, este indica el tipo de investigación empleada para resolver el problema presente en la PUCE SD, se determina la población, la muestra; así, como los instrumentos y técnicas que se utilizaron para la recolección de datos. También se menciona la metodología XP (Extreme Programming - Programación Extrema), que se aplicó para determinar las etapas
e instrumentos que sustentan un
desarrollo de software ágil y efectivo. En el Capítulo 5,
se emite el análisis y discusión por cada resultado
obtenido en el desarrollo del SADG, estos se desprenden de los objetivos planteados inicialmente. En este apartado también se redactan las conclusiones finales y recomendaciones, en relación al software para la administración de disertaciones de grado en la PUCE SD. La última sección de la disertación incluye Material de Referencia, se presenta la bibliografía, lincografía, hemerografía que sirvieron como fuente para el sustento teórico en el desarrollo de la disertación de grado. Finalmente están el glosario de términos con la definición de las palabras y siglas pocos comunes que se emplearon y los anexos de la disertación.
2. PLANTEAMIENTO DEL PROBLEMA 2.1. Antecedentes La PUCE SD realiza gran parte de la administración de proyectos de disertación de grado en forma manual, por tal motivo existen tiempos excesivos e inconvenientes al momento de trabajar con la información. El método para el seguimiento de los avances de disertaciones es inadecuado, debido a los aspectos que se mencionan a continuación:
Se carece de coordinación en cuanto a la actualización de registros sobre las etapas de desarrollo de los proyectos.
Se
generan
varias
copias,
de
los
archivos
lo
que
ocasiona
inconsistencias al momento de registrar y consultar la información sobre las disertaciones de grado.
El acceso a ésta información no cuenta con la seguridad necesaria y la dificultad para recopilar la información es producto de una falta de organización.
La dificultad que se presenta en la fluidez de comunicación que se realiza vía interpersonal o telefónica, entre los tutores de disertaciones de grado, secretarías de escuela y directores de escuela, disminuye la eficiencia en cuanto a la actualización de información.
Al momento de requerir el estado de las disertaciones de grado, la situación de los estudiantes, los reportes de avances; se dificulta la tarea de recopilación de información por la ausencia de un sistema que soporte todo el proceso. El trabajo de administración de disertaciones de grado se realiza mediante el uso de herramientas tradicionales de ofimática de Microsoft tales como Excel 3
4
y Word, lo que conlleva a la confusión en el manejo de los archivos, actualizaciones erróneas y crecimiento de
documentación
sin
una
justificación efectiva. Los períodos establecidos para el desarrollo de las disertaciones de grado se extienden en repetidas ocasiones por la ausencia de alertas que faciliten medir los tiempos para cada actividad contenida en el proyecto. En la Figura 1 se presenta el modelo árbol del problema, con el cual se identifican las Causas y Efectos del Problema.
Malestar en usuarios
Tiempo exagerado en obtención
Incremento de errores
de resultados
involuntarios
Deficiente eficacia y eficiencia en el proceso de administración de disertaciones de grado
Poca utilización de tecnología en
Procesos manuales en manejo
la administración de
de información de disertaciones
disertaciones de grado.
de grado.
Figura 1: Árbol del Problema en administración de disertaciones de la PUCE SD. Fuente: Los Autores.
5
2.2. Problema de Investigación La PUCE SD no cuenta con un sistema informático para la administración de proyectos de disertación de grado. Las solicitudes son atendidas sin promedio de tiempo estimado y el seguimiento del avance de las disertaciones de grado
se registra conforme llegan a los departamentos
encargados del proceso, se registra información en hojas de excel y para localizar e imprimir un reporte, se requiere un análisis previo que tarda un tiempo excesivo. El proceso de administración de disertaciones de grado se realiza mediante el uso de herramientas tradicionales de ofimática de Microsoft tales como:
Excel: para el ingreso de avances a las fichas de los egresados.
Word: para elaboración de reportes.
El control de acceso a toda la información no se efectúa adecuadamente, lo que disminuye la seguridad y contribuye a una falta de organización, restando el poder de toma de decisiones a nivel estratégico. En la actualidad todo proceso manual genera inconvenientes, errores en resultados, demora en el tratamiento de la información, y sobre todo búsqueda de información dispersa. La deficiente utilización de tecnología genera transacciones que estiman un tiempo demasiado excesivo en la administración de disertaciones de grado y promueve el retraso en los procesos que se manejan.
6
2.3. Justificación La implementación del SADG, se presenta como solución para los inconvenientes que se generan en el proceso de administración de disertaciones de grado de
la PUCE SD. En tal virtud, se justifica esta
investigación por los siguientes argumentos:
Propone Innovación Tecnológica, incorporando procesos automatizados y uso de tecnología de la información para integrar todo un proceso al sistema informático que van a utilizar los usuarios.
La aplicación propuesta como solución a la necesidad de los usuarios, se desarrolló a medida, bajo los requerimientos de la PUCE SD.
Brinda respuesta inmediata a las consultas por parte de dirección académica, coordinadores de Investigación aplicada, directores y secretarias de escuela; esto permite a los participantes de todas las escuelas de la PUCE SD estar al tanto del estado real de las disertaciones de grado, garantiza una mejor organización y la facultad de tomar decisiones.
SADG permite controlar el acceso a los registros e información, a través de una interfaz orientada a la web funcional, con perfiles de usuario que interactúan con el sistema según las necesidades y permisos asignados respectivamente para cada caso.
Propone incorporar alertas, que notifican al usuario en las fechas previas al vencimiento del plazo, para desarrollo de proyectos.
El software cuenta con un módulo de generación de reportes y gráficos estadísticos para complementar la presentación de los datos, con el fin de facilitar la interpretación de resultados.
Genera un interés por administrar con mayor eficiencia y eficacia los procesos del personal involucrado, con el apoyo de los recursos tecnológicos y conocimiento disponibles.
7
2.4. Objetivos 2.4.1. Objetivo General Desarrollar e implementar una aplicación web para la administración de disertaciones de grado en la Pontificia Universidad Católica del Ecuador sede Santo Domingo. 2.4.2. Objetivos Específicos
Realizar el levantamiento de información para obtener los requerimientos para el desarrollo del Sistema de administración de disertaciones de grado.
Diseñar el Sistema de administración de disertaciones de grado en base a los requerimientos.
Codificar e implementar el Sistema de administración de disertaciones de grado.
Ejecutar las pruebas de aceptación.
Realizar la entrega del Sistema de administración de disertaciones de grado.
3. MARCO REFERENCIAL 3.1. Revisión de la literatura o fundamentos teóricos En este capítulo se incorporan los conceptos teóricos
que respaldan el
desarrollo del proyecto; con un enfoque centrado en las herramientas tecnológicas, entornos operativos y lenguajes de programación que permitieron cumplir el objetivo del mismo. Se exponen también conceptos de ingeniería de software, herramientas de desarrollo para sistemas web, herramientas para gestión de Base de Datos, conceptos sobre las metodologías utilizadas, los elementos que un aplicativo web posee, el diseño, su arquitectura, la seguridad implementada y además, el modelo de objetos de la base de datos y la aplicación. 3.1.1. IDE Eclipse Es una plataforma desarrollada por IBM como una de sus herramientas y actualmente pertenece a la Fundación Eclipse, que apoya a la comunidad de código libre. Eclipse permite ampliar sus capacidades instalando plugins adicionales como módulos y aplicaciones de desarrollo para otros lenguajes de programación. El mismo entorno de desarrollo es capaz de incorporar diversidad de lenguajes como UML (Unified Modeling Language – Lenguaje Unificado de Modelado), HTML (HyperText Markup Language – Lenguaje de Marcas de Hipertexto), lo que concede al usuario la ventaja de aplicar la reingeniería inversa, además cuenta con librerías en la web de gran utilidad cuando se requiere actualización y soporte. La manipulación del código raíz en Eclipse brinda al desarrollador mayor acceso en cuanto al control de las propiedades e interacción de los objetos.
8
9
Figura 2: Entorno Eclipse. Fuente: Los Autores.
3.1.2. IDE NetBeans Es un entorno de desarrollo libre, creado principalmente para programar en Java, también permite extenderse por módulos para adoptar diversos lenguajes de programación, entre ellos PHP. Con esta herramienta se tiene la capacidad de estructurar de manera organizada los elementos como archivos y carpetas del proyecto para un fácil acceso y manejo de los mismos, es ideal para el paradigma orientado a objetos y se adapta según el enfoque que aplica el desarrollador. Entre las características
más destacables se valoran la calidad que
garantiza la aplicación en el producto final, su facilidad de usar, existe suficiente información y asistencia gracias a su popularidad, simplifica y agilita el diseño en la programación.
10
En cuanto a las actualizaciones más recientes que brinda el IDE (Integrated Development Environment – Entorno de Desarrollo Integrado) NetBeans está el soporte para desarrollo de programas orientados a la Web, aplicaciones móviles, entre otras.
Figura 3: Entorno NetBeans. Fuente: Los Autores.
3.1.3. Base De Datos Para Camps (2002: 8), “Una base de datos es un conjunto estructurado de datos que representa entidades y sus interrelaciones”. En una BD (Base de Datos) se recopila información, que se encuentra almacenada en un ordenador y está organizada mediante tablas con sus respectivos campos o atributos, estos últimos definen la forma de distribuir los datos en tablas.
11
Entre las características que ofrece la administración de información mediante bases de datos se tienen:
Permiten almacenar la información de manera digital.
Facilitan la clasificación de los datos.
Se puede conceder o filtrar el acceso a la información mediante perfiles o esquemas de usuarios.
Las transacciones de consulta y manipulación de datos pueden realizarse en forma remota hacia bases de datos centralizadas o distribuidas.
Llanos (2010) considera, que una BD debe cumplir los requisitos expuestos a continuación:
No debe existir redundancia lógica de datos, los datos deben estar almacenados una vez aunque el sistema los pueda replicar.
Dar soporte a múltiples usuarios y aplicaciones simultáneamente.
Debe existir independencia física como lógica entre datos y proceso.
Las definiciones y descripciones del conjunto de datos contenidos en la base deben ser únicas y estar integradas con los mismos datos.
Debe asegurar integridad, seguridad y confidencialidad de los datos cuando se cargan y actualizan.
3.1.3.1.
Sistema Gestor de Base de Datos
Un SGBD (Sistema Gestor de Base de Datos), es el que se encarga de realizar operaciones sobre la información dispuesta en la base de datos, como su nombre lo indica se ocupa de la gestión de las transacciones que se generan entre los usuarios y la base.
12
Entre los gestores más utilizados según el ranking de Classora (2008) están: Oracle, PostgreSql, MySQL y SQL Server, los mismos que poseen lenguajes de manipulación y tratamiento de información similares, lo cual permite que la migración entre uno y otro sea posible. 3.1.3.2.
Oracle Database
Figura 4: Oracle Database 11g Fuente: www.7chip.com
Oracle Database es un sistema gestor de base de datos muy popular, principalmente se caracteriza por poseer una gran potencia en el proceso de transacciones, además destacan la seguridad que brinda y el amplio nivel de escalabilidad que ofrece haciéndolo ideal para grandes empresas. Las versiones de Oracle tanto gratuitas como pagadas tienen un gran desempeño en diversos sistemas operativos, y mantienen su compatibilidad en el caso de requerir una migración de información de una versión a otra. Oracle Corporation (2009) introdujo la versión 11g XE, reafirmándola como una de las plataformas actuales, más potente y con muchas prestaciones ideal para el trabajo con informes y análisis de la información que manejan las grandes empresas; esto con el fin de dar un mayor énfasis a la inteligencia de negocios, es decir a más de manejar datos se tiene la
13
capacidad de interpretarlos y analizarlos para tomar decisiones en favor del crecimiento empresarial. Con Oracle Fast Files al trabajar con archivos pesados como imágenes, documentos XML, entre otros, se garantiza una rapidez en transacciones con gran cantidad de información que hoy en día es muy común procesar en las aplicaciones. Es fundamental para Oracle priorizar la gestión correcta de recursos de tecnología, al ejecutar con eficiencia las transacciones sobre la base de datos para optimizar el uso de los recursos tecnológicos que disponen los usuarios del sistema gestor de base de datos. 3.1.3.3.
Oracle SQL Developer Data Modeler
Figura 5: Entorno Oracle SQL Developer Data Modeler. Fuente: Los Autores.
14
Esta herramienta genera el modelado de la base de datos, obteniendo los objetos de una base alojada localmente, o ya sea mediante la creación de nuevas entidades para su posterior manipulación y relación, dependiendo del caso. El entorno de este modelador es muy amigable y permite manipular todos los elementos que se utilizan de manera ágil ya que está orientado a bases de datos Oracle e incorpora el lenguaje de Modelado Unificado. 3.1.4. PHP
Figura 6: Logo php. Fuente: www.php.net
PHP es un lenguaje de programación diseñado para la creación de páginas web dinámicas ya sean sencillas o muy avanzadas, que además permite el acceso a información almacenada en una base de datos, contiene gran cantidad de soporte
y funciones que pueden extenderse para solventar
muchas exigencias que se presentan en la codificación de aplicaciones web. Trabaja como un código oculto que es ejecutado por el servidor, el mismo que es traducido a HTML para su presentación. Programar en php ofrece compatibilidad con los gestores de base de datos actuales, su configuración afianza la seguridad en las transacciones y conexiones, por medio de módulos o extensiones que pueden incorporarse de forma confiable. 3.1.4.1.
OCI8
OCI8 es un conjunto de funciones que permiten la conexión a bases de datos Oracle, a través de los lenguajes SQL y PL/SLQ para el tratamiento y manipulación de registros; mediante los cuales la información contenida en
15
los objetos puede ser creada, leída, actualizada y eliminada, cumpliendo así con las operaciones que ofrecen los sistemas gestores de base de datos o las capas de persistencia que ofrece un sistema. OCI8 no es un set de herramientas contenidas en el paquete de software Oracle, sino más bien un complemento para el código de lado del servidor interpretado por PHP, ésta extensión de funcionalidad no viene habilitada por defecto en el host web, es menester del programador o administrador configurarlo para acceder al mismo. 3.1.5. AJAX
Figura 7: Funcionamiento de AJAX Fuente: http://www.w3schools.com/ajax/ajax_intro.asp
En una publicación de Eguíluz (2008) se considera a AJAX (Asynchronous JavaScript and XML - JavaScript y XML Asíncronos) como un conjunto de tecnologías, que permite que las aplicaciones funcionen mucho más rápido, ya que la estructura de la página se carga y actualiza por secciones, teniendo así la ventaja de controlar cada elemento de manera independiente y a la vez reducir el consumo de memoria.
16
La interacción que AJAX brinda con el usuario y los sitios dinámicos es tan potente y posiciona a esta herramienta entre una de las más populares y de mayor aceptación por los desarrolladores de sistemas orientados a la web. Combina las tecnologías XML para datos y JavaScript para funciones y operaciones del servidor asegurando eficiencia y flexibilidad en la ejecución de transacciones del sitio. 3.1.6. XML Es un lenguaje de etiquetas extensible similar a HTML, que principalmente se orienta a la manipulación de grandes flujos de datos, posee una estructura en forma jerárquica, que por medio de marcas organiza el contenido; al trabajar con gran cantidad de información resulta muy útil en el empleo de transferencias entre documentos web y bases de datos. Se caracteriza por su simplicidad y seguridad para el intercambio de datos que puede compartirse entre diferentes plataformas. 3.1.7. JAVASCRIPT
Figura 8: Logo JavaScript Fuente: http://ocpsoft.org/opensource/javascript-is-the-new-perl/
Se utiliza en la programación web, propicia la interacción con el navegador de manera más dinámica, genera efectos visuales muy atractivos.
17
JS (Java Script) se escribe en documentos HTML, por lo tanto es necesario que se incorporen determinados tags o marcas propias del lenguaje de manera que HTML reconozca que se trata de un script de JavaScript, ver Figura 9.
Figura 9: Estructura JavaScript Fuente: Los Autores
Las acciones que se pueden realizar en JavaScript van desde generar animaciones, manipular atributos de los elementos de la página, modificar el color, tamaño, generar sombras; la creación de ventanas emergentes con este lenguaje, es otra solución que incrementa la interacción entre el usuario y la aplicación web, se obtiene un acceso más eficiente a los módulos siempre y cuando se tome en cuenta un diseño organizado y estructurado de los menús. Una característica importante es que JavaScript se ha desarrollado en base al lenguaje Java, con relación a los diferentes tipos de datos y estructuras de control; además el código no se compila porque trabaja con memoria dinámica la misma que manipula los objetos de forma individual y los descarta cuando no son utilizados. En una introducción sobre JavaScript, Eguíluz (2008) publica las normas básicas que definen su sintaxis:
En JS no se tienen en cuenta los espacios en blanco y las nuevas líneas.
Se distinguen mayúsculas y minúsculas.
18
No se define el tipo de variable.
No es necesario terminar cada sentencia con el carácter de punto y coma.
Se puede incluir comentarios.
3.1.7.1.
JQuery
JQuery es una herramienta de gran utilidad para entornos web, está compuesta en lenguaje JavaScript el cual concede el poder de implementar animaciones, manipular el DOM (Document Object Model - Modelo de Objetos del Documento) y aplicar tecnología AJAX en páginas Web. Se puede incluir en cualquier tipo de plataforma ya que es de licencia gratuita y además es compatible con la mayoría de navegadores actuales. La creación de efectos y el diseño de interfaces, se simplifican al trabajar con JQuery, por lo que resulta indispensable su uso en aplicaciones que requieren un gran desempeño visual. 3.1.8. DOM En una traducción
que realizó Pozo (2001), se explica que el DOM se
refiere al modelo de objetos de documentos web, trabaja sobre la estructura y manipulación con archivos en lenguaje HTML y XML. Permite acceder a las
propiedades
de
los
elementos
de
una
página,
para
realizar
modificaciones y adaptar los proyectos según los requerimientos que se solicitan para el correcto desempeño de la aplicación web. La compatibilidad con los navegadores es una de las razones por las que surgió el DOM, se logra estandarizar un modelo adecuado para todos los navegadores, sin embargo algunas versiones necesitan extensiones adicionales.
19
Figura 10: Una visi贸n de la arquitectura de DOM Fuente: http://www.w3.org/2005/03/DOM3Core-es/introduccion.html
3.1.9. MVC
Figura 11: Diagrama del patr贸n de Arquitectura de Software MVC Fuente: Trygve Reenskaug
20
MVC (Model View Controller - Modelo Vista Controlador), se trata del tipo de arquitectura en que los programas separan su estructura por capas, ver Figura 11. En un estudio de Cake Software Foundation, Inc. (2014) estas capas se definen de la siguiente manera: En la capa del modelo se establecen ciertas reglas sobre el negocio que van a implementarse en el programa, esta capa se define aparte debido a la facilidad que permitirá para realizar cambios que surgen constantemente en toda institución. La vista define la parte de presentación de la aplicación, también es fundamental contemplar este nivel independientemente para configurar el diseño cuando se requiera, ya sea por cambios requeridos o necesarios por ejemplo cuando se redefinen formularios, colores y funcionalidad. La capa controlador se encarga de administrar las peticiones, acciones entre el usuario y la aplicación, realiza las solicitudes al modelo y genera las actualizaciones de vista que se presentarán. 3.1.10.
CSS
CSS (Cascading Style Sheets - Hojas de Estilo en Cascada), son de mucha utilidad para el diseño de una página web; poseen la característica de definir la forma de presentación aplicada a un sitio completo, partes y componentes del mismo; como pueden ser tablas, etiquetas entre otros. Con la aplicación de esta tecnología se simplifica la programación web, eliminando la reiteración de código, además de establecer una definición más estructurada de cada sección de una página. A diferencia del lenguaje html, las hojas con estilo en CSS a más de porcentajes y pixeles, manejan unidades para definición de los atributos como pulgadas, puntos y centímetros.
21
El funcionamiento de CSS como lo expone en su publicación Eguíluz (2009), está basado en la definición de términos, mismos que describen cada parte que compone los estilos CSS. A continuación se expone una breve definición de cada uno de estos términos:
Regla: Cada uno de los estilos que componen una hoja de CSS, se compone de un selector y una declaración.
Selector: Indica el elemento al que se aplica la regla CSS.
Declaración: Especifica los estilos que se aplican a los elementos.
Propiedad: Manipula el aspecto de una característica del elemento
Valor: Indica el valor de una característica del elemento.
Figura 12: Componentes de un estilo CSS básico. Fuente: http://librosweb.es/css/
El selector precede a las declaraciones agrupadas entre llaves, para separar las declaraciones se utiliza el punto y coma; muy común en diversos lenguajes de programación, ver Figura 12.
22
En el caso de vincular la hoja de estilos a un documento externo, que es lo más adecuado, se debe especificar la ruta donde se encuentra el documento dentro del elemento <link>, el mismo que es declarado en la sección cabecera de la página, como se puede apreciar en el código a continuación: <link rel="stylesheet" type="text/css" href="C:/estilos/SADG_main.css"/> 3.1.11.
Encriptación de datos
Es un proceso que proviene de la ciencia de Criptología, que se encarga de ocultar información mediante la transformación de información a códigos que se obtienen empleando técnicas matemáticas o simples permutaciones. El objetivo de la encriptación de datos es la protección de claves e información confidencial que va a ser trasmitida o almacenada por los usuarios. La interpretación o desencriptación de los datos encriptados es opcional, ya que ciertos métodos no permiten recuperar el texto original. 3.1.11.1. MD5 Es un algoritmo que trabaja con 128 bits representados en 32 dígitos hexadecimales, su fin principal es la seguridad en la informática, se desarrolló para comprobar la suma de archivos descargados en la red por los usuarios. Algunos sistemas como Linux emplean md5 para el cifrado de contraseñas de usuarios, simplemente se almacena la clave cifrada en el servidor al registrar el nuevo usuario, para después en la autenticación comparar con la clave de logueo. Para realizar encriptación en php se trabaja con la función Message Digest 5 (Md5), ésta función realiza el proceso de encriptación de las claves, lo que asegura que para acceder a la clave procesada por la función y almacenada en la base de datos del servidor, solo se lo puede hacer partiendo desde la clave original.
23
3.1.12.
Highcharts
Figura 13: Logo Highcharts Fuente: www.highcharts.com
Highcharts, es una herramienta que permite desarrollar gráficas de manera interactiva en los navegadores web, ideales para apoyar informes de una empresa o institución con enfoque estadístico y dinámico. Estas representaciones pueden generarse perfectamente en computadores personales, teléfonos celulares y tabletas que dispongan de un navegador que soporte Html5 y JavaScript. Las gráficas animadas que permite generar van desde histogramas, barras, columnas, pasteles, dispersión, entre otras; además brinda la capacidad de exportación a archivos como PDF, PNG, JPG. La licencia de Highcharts es de uso libre para sitios personales y educativos. 3.1.13.
Licencias de software
El desarrollo de software engloba diversos aspectos, en el tema legal es oportuno tomar en cuenta las licencias, tanto para las aplicaciones que se adquieren o despliegan. Al adquirir un programa se acepta un acuerdo sobre los permisos que el autor establece para el uso o distribución del mismo; eso garantiza el compromiso y la conformidad del usuario con la aplicación que va a obtener. Existen varios tipos de software, los que han ido surgiendo con el tiempo en base a la experiencia y filosofía que han adquirido los desarrolladores, entre los que destacan:
24
Para empezar el software privativo, que imponen sus condiciones de uso al usuario sobre el programa, éste puede ejecutarse sin ser modificado, ni revisar el código fuente; lo que coloca al cliente en una posición de dependencia con el desarrollador.
Por otra parte según Martínez y Lara (2007: 15), software libre es: Aquel software, producto o desarrollo a medida, que se distribuye bajo una licencia, según la cual el autor cede una serie de libertades básicas al usuario en el marco de un acuerdo de concesión. Estas libertades de los usuarios del software, recogidas en la filosofía de la Fundación para el Software Libre (Free Software Foundation), son: la libertad de usar el programa con cualquier propósito; la libertad de estudiar cómo funciona el programa y adaptarlo a sus necesidades; la libertad de distribuir copias; y la libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie.
En cuanto al Freeware o software gratuito, se refiere a un programa que puede ser descargado y ejecutado sin costo alguno; sin disponibilidad de su código fuente.
Finalmente está el Shareware que es muy similar al Freeware, pero su uso gratuito es por un tiempo determinado, posterior se debe pagar una licencia.
3.1.13.1. Licencia GNU GPL Esta licencia nace con los inicios del software libre y es la base de su filosofía, en base al proyecto GNU, la Licencia Pública General de GNU creada por Richard Stallman según una publicación de Romero (2007), con el propósito de erradicar las restricciones que el software privativo impone a los usuarios, y protegiendo sus derechos con las leyes de copyright en las que generalmente se amparan los desarrolladores para restringir sus obras.
25
3.1.13.2. Licencia Creative Commons
Figura 14: Logo creative commons Fuente: www.creativecommons.org
CC (Creative Commons) son licencias que permiten la libre copia edición y distribución de los conocimientos declarados como comunes, según los permisos que el autor de la obra original conceda. Su enfoque va de la mano de la necesidad que existe a nivel mundial de crear y compartir el bien común. Un aspecto importante de las licencias CC son las condiciones que se imponen en el uso de las mismas, brindan mayor libertad al autor, puesto que es él quien tiene el poder sobre los derechos que impone a su obra para compartirla. Todas las versiones de CC tienen Atribución, es decir se debe dar crédito al autor de la obra principal, y las alternativas que ofrecen CC versión 4.0 son diversas, ver Tabla 1.
Logo Licencia
Tipo / Denominación
Atribución CC BY
AtribuciónCompartirIgual CC BY-SA AtribuciónSinDerivadas CC BY-ND
Términos y Condiciones
distribuir, remezclar, retocar, incluso con fines comerciales.
y crear,
remezclar, retocar, y crear, incluso con fines comerciales, siempre y cuando licencien sus nuevas creaciones bajo las mismas condiciones. redistribución, comercial o no comercial, siempre y cuando la obra circule íntegra y sin cambios.
26
AtribuciónNoComercial CC BY-NC
distribuir, remezclar, retocar, y crear de manera no comercial y mantenerse sin fines comerciales, no están obligados a licenciar sus obras derivadas bajo las mismas condiciones.
AtribuciónNoComercialCompartirIgual CC BY-NC-SA
distribuir, remezclar, retocar, y crear de modo no comercial, siempre y cuando licencien sus nuevas creaciones bajo las mismas condiciones.
AtribuciónNoComercialSinDerivadas CC BY-NC-ND
solo descargar la obra y compartirla con otros, pero no permiten cambiarlas de forma alguna ni usarlas comercialmente.
Tabla 1: Tipos Licencias CC Fuente: http://creativecommons.org/licenses/
3.1.13.3. Licencias MIT Esta licencia se caracteriza por ser muy permisiva, sus permisos van desde el uso, modificación, redistribución del software con la condición de extender una copia del producto que se despliega al final. Otra consideración relevante sobre MIT es que su redistribución puede realizarse tanto como software libre o software privativo, según el enfoque del desarrollador. 3.1.14.
Single Page Interface
Como su nombre lo indica, el SPI (Single Page Interface – Interfaz de Pagina Individual) se enfoca en el trabajo de una interfaz única, todas las operaciones se cargan en el mismo sitio, con una interacción y navegación muy ágil para el usuario, lo que implica un nivel de programación avanzada, que es posible gracias a herramientas como AJAX, CSS, entre otros. En el Single Page Interface Manifesto (2011) destacan las siguientes características de SPI:
Utiliza un modelo MVC basado en componentes y eventos, parcial o parte de una página de acuerdo a una acción.
cambio
27
Trabaja con dos estados en lugar de páginas; el estado fundamental que son los sitios principales y el estado secundario como las ventanas modales, eventos, o mensajes sobre la página principal.
Los botones Atrás y Adelante son simulados cambiando al estado visitado previo o siguiente.
3.1.15.
Patrón Singleton
Singleton es un patrón de desarrollo que logra reducir las llamadas a objetos mediante la única instancia de clases, ver Figura 15. Su implementación reduce el uso de memoria, se enfoca en la reutilización y eficiencia del código para un mejor desempeño y respuesta inmediata de los programas. Se utiliza regularmente en las conexiones a base de datos llamado a la
través del
instancia de un objeto, mismo que contiene todos los
parámetros de conexión a la BD.
Figura 15: Diagrama de Modelo de Objetos Patrón Singleton Fuente: http://msdn.microsoft.com/es-es/library/bb972272.aspx
28
3.2. Hipótesis de trabajo
El sistema de administración de disertaciones de grado será la solución para el control y seguimiento efectivo de las disertaciones de grado en la PUCE SD.
3.2.1. Matriz operacional de las variables
Variable Independiente
Definición conceptual
Definición operacional
Sistema de administración de disertaciones de grado.
Entorno de aplicación Web para administración y seguimiento de las disertaciones de grado de la PUCE SD.
Gestión de Alumnos disertantes.
Indicadores
Tiempo de generación de reportes.
Gestión de Directores. Procesos Gestión de Proyectos de
Automatizados.
Disertación de Grado. Registros
Gestión de Líneas de Investigación.
Almacenados.
Autenticación de Usuarios.
Tabla 2: Matriz operacional de la variable Independiente. Fuente: Los Autores.
29
Variable dependiente
Definición conceptual
Definición operacional
Control y seguimiento efectivo de las disertaciones de Grado.
Proceso de administración de disertaciones de grado de la PUCE SD.
Seguimiento de Estudiantes en proceso
Indicadores
Indicadores Estadísticos.
de disertación de Grado.
Seguridad de Monitoreo de Tutores de disertaciones de Grado.
Clasificación de Proyectos de Disertación.
Tabla 3: Matriz operacional de la variable Dependiente. Fuente: Los Autores.
registros.
4.
METODOLOGÍA DE LA INVESTIGACIÓN
4.1. Diseño / Tipo de investigación En esta sección se explica en
que consiste cada metodología, método,
técnica de investigación y se describe la forma de aplicación de las mismas en el desarrollo del proyecto de disertación de grado intitulado “Desarrollo e implementación de una aplicación web para la administración de disertaciones de grado en la PUCE SD”. 4.1.1. Investigación Descriptiva Esta investigación identifica las características principales del problema de estudio, para describir sus propiedades y como se presentan en la realidad. La investigación descriptiva se aplica ampliamente en la educación. Aplicación: Para la aplicación en la PUCE SD, se describe en forma concreta lo sucedido con el objeto de estudio, en este caso la administración de disertaciones de grado y todos los elementos que conforman el proceso. Se determina con la investigación descriptiva los componentes principales de la investigación que se realizó. 4.1.2. Investigación Aplicada La investigación Aplicada busca resolver problemas reales, respondiendo a preguntas específicas, es decir da solución a problemas conocidos en forma práctica. Aplicación: En el caso de la PUCE SD, se analizó el problema de investigación
minuciosamente
para
dar
solución
práctica
a
los
inconvenientes que se presentaron en el proceso de administración de las disertaciones de grado.
30
31
4.1.3. Investigación de Campo La investigación de campo se aplica con el fin de obtener nuevos conocimientos de una sociedad o grupo, para diagnosticar un problema o necesidad. Esta investigación se realiza en el lugar a ser estudiado empleando técnicas como la observación, entrevista, entre otras. Aplicación: Se aplicó la investigación de campo debido a la necesidad de realizar un estudio en el lugar, en este caso la Universidad y específicamente los departamentos vinculados directamente al problema, estableciendo una interacción entre los objetivos de estudio y realidad actual. 4.1.4. Método Deductivo El método deductivo consiste en la observación de fenómenos generales, con el propósito de llegar a hechos particulares. Aplicación: Se realizó un estudio en forma general, de soluciones de aplicación los
web, para el desarrollo del sistema informático, basándose en
requerimientos
obtenidos
particularmente
en
el
proceso
de
administración de disertaciones de grado en la PUCE SD.
4.2. Población / Universo La Población es el total de unidades, individuos u objetos involucrados en el estudio o fenómeno de investigación, este valor se define con precisión, para garantizar
la efectividad en los resultados que genera el proyecto
investigativo. En base a la población, se obtiene la muestra, que será el total o una parte del universo de acuerdo al problema de investigación. Aplicación:
Para obtener la población o universo del proceso de
administración de disertaciones en la PUCE SD, se efectuó un conteo de los participantes por cada departamento.
32
AsĂ se concluye que existen 4 departamentos involucrados, DirecciĂłn AcadĂŠmica, CoordinaciĂłn de InvestigaciĂłn Aplicada, DirecciĂłn de Escuelas, SecretarĂas. Finalmente se obtuvo un total de 18 individuos para la poblaciĂłn que se estudiĂł en el proyecto.
4.3. Muestra Para determinar la muestra de una poblaciĂłn se debe tener en cuenta que el estudio de la misma implica la utilizaciĂłn de recursos y ademĂĄs que los resultados obtenidos reflejan las tendencias y caracterĂsticas de los individuos investigados; los cuales son la pauta para emitir conclusiones del fenĂłmeno de estudio. La muestra puede ser finita que representa el total de la poblaciĂłn, o infinita que abarca una parte de la poblaciĂłn. Se calcula utilizando la fĂłrmula definida de la siguiente manera:
n=
đ?&#x2018;§ 2 đ?&#x2018;&#x192;đ?&#x2018;&#x201E;đ?&#x2018; đ?&#x2018;§ 2 đ?&#x2018;&#x192;đ?&#x2018;&#x201E; + đ?&#x2018; đ?&#x2018;&#x2019; 2
dĂłnde: n= TamaĂąo de la muestra Z= nivel de confiabilidad: 95% (Z=1,96) P= Probabilidad de ocurrencia: 0,5 Q= Probabilidad de no ocurrencia: 1 â&#x20AC;&#x201C; 0,5 = 0,5 N= PoblaciĂłn e= error del muestreo (entre 1% y 9%): 5% recomendable
33
Aplicación: En el proceso de administración de disertaciones de grado de la PUCE SD, la población es menor a 30 personas, por ello, no se aplica la fórmula para obtener la muestra, y se procede a realizar un censo es decir, se consideró el total de 18 personas a quienes se aplicaron encuestas y entrevistas para la recolección de datos. La muestra total se encuentra distribuida, se registra el número de personas participantes por cada departamento, ver Tabla 4.
Departamento
Número de Personas
Dirección de Escuelas
7
Secretaría
6
Dirección Académica
4
Coordinación Investigación Aplicada
1 18
TOTAL MUESTRA Tabla 4: Participantes en el proceso de administración de disertaciones de grado. Fuente: PUCE SD
4.4. Instrumentos de recogida de datos 4.4.1. Análisis Bibliográfico El análisis bibliográfico se refiere a las consultas en textos y documentos externos para sustentar los conocimientos teóricos que emplea el investigador en el desarrollo del proyecto, estos documentos generalmente son: libros, revistas, publicaciones en diarios, guías, disertaciones de grado, páginas web, etc.
34
Aplicación: En la aplicación de técnicas se trabajó con el análisis bibliográfico para obtener el apoyo necesario en textos, y documentos en línea relacionado con el desarrollo de software orientado a la web, con las características que requeridas por el proyecto a desarrollar. 4.4.2. Observación Observar es aplicar atentamente los sentidos a un objeto o a un fenómeno, para estudiarlos tal como se presentan en realidad, puede ser ocasional o causalmente. Aplicación: Se aplicó la observación para la recogida de datos en la PUCE SD, por ser una técnica de bajo coste, que además proporcionó información valiosa para una mejor comprensión del proceso de administración de disertaciones de grado. 4.4.3. Inducción La acción y efecto de extraer, a partir de determinadas observaciones o experiencias particulares, el principio particular de cada una de ellas. Aplicación: Se realizó la investigación en cada escuela y departamento encargado de administrar las disertaciones de grado, para extraer por medio de la inducción el enfoque general implementado en el proceso. Además se analizó la matriz utilizada en Excel en la PUCE SD para la administración de disertaciones y la descripción sobre el modelo de las tablas del sistema académico, ver Anexo 1. 4.4.4. Encuesta La encuesta es una técnica que permite obtener datos reales sobre la percepción que tiene la población con el problema de investigación, a su vez se formula un cuestionario con preguntas claras, abiertas o cerradas; sin sugerir una respuesta al encuestado, con el fin de demostrar que la solución propuesta es necesaria aplicarse.
35
Las encuestas se tabulan en un marco objetivo y en donde las respuestas presentan un enfoque totalmente valido para la toma de decisiones y justificación del proyecto. Aplicación: Se encuestó a todos los participantes en el proceso de administración de disertaciones de grado de la PUCE SD, con preguntas cerradas que facilitan el análisis de la situación que se presenta, ver Anexo 2. 4.4.5. Entrevista La entrevista es una conversación directa entre el investigador y el individuo u objeto de estudio, también emplea el cuestionario como instrumento; cabe destacar que se puede aplicar dos tipos de entrevista:
Estructurada: Este tipo de entrevista establece un cuestionario, con preguntas fijas que se realizará al entrevistado.
No Estructurada: En esta entrevista se generan preguntas conforme va avanzando la entrevista, se mantiene una secuencia en las preguntas, para poder analizar con facilidad los datos que se obtienen.
Aplicación: Se entrevistaron a los participantes encargados de la administración de disertaciones de grado de la PUCE SD, en cada uno de los
departamentos
respectivos
como
son:
Dirección
Académica,
Coordinación de Investigación Aplicada, Secretaría y Dirección de Escuelas; que son la fuente principal de información relacionada al proceso que se va a apoyar con el sistema, debido a su interacción y participación directa con el mismo, ver Anexo 3. 4.4.6. Cuestionario En el cuestionario se redactan las interrogantes, para obtener información acerca del objeto o fenómeno de estudio, éste puede ser aplicado en forma individual o colectiva.
36
La elaboración de un cuestionario ideal supone una estructura u orden en la construcción del mismo; con preguntas cuantificables y accesibles para los interrogados, además debe ser objetivo y centrarse en el tema de estudio. Generalmente los cuestionarios pueden clasificarse en tres tipos, de la siguiente manera:
Cuestionario abierto.- Contiene preguntas abiertas, es decir no sugiere alternativas, el sujeto interrogado redacta las respuestas a ser interpretadas, tabuladas o resumidas.
Cuestionario cerrado.- Las preguntas en este tipo de cuestionario son cerradas, es decir, se delimitan las alternativas, el sujeto señala una o varias opciones emitidas en el cuestionario como opciones de respuesta.
Cuestionario mixto.- Este tipo de cuestionario abarca preguntas abiertas y cerradas.
Aplicación: Se redactaron dos tipos de cuestionario en la investigación realizada en la PUCE SD, para las entrevistas se formularon preguntas abiertas, con un cuestionario semiestructurado, ya que se incorporaron preguntas relacionadas con las respuestas de los entrevistados. Para las encuestas, se empleó el cuestionario cerrado, con preguntas dicotómicas, de escala y de opción múltiple.
4.5. Técnicas de análisis de datos Los datos obtenidos con los instrumentos de investigación, son analizados con herramientas que permiten su organización. A continuación se describen el tipo de análisis de los datos que todo proceso investigación maneja. 4.5.1. Análisis Cuantitativo El análisis de datos cuantitativo o de cantidad, como su nombre lo indica, representa los datos en forma numérica y por lo general, se apoya en técnicas estadísticas.
37
Aplicación: Para analizar los datos de las encuestas realizadas se realizó la tabulación
de
las
encuestas
aplicadas a
los
participantes
en
la
administración de disertaciones de grado de la PUCE SD. 4.5.2. Análisis Cualitativo En el análisis cualitativo o de cualidad, se describe en forma gráfica o verbal las características o tendencias de los datos obtenidos a partir del fenómeno de estudio. Aplicación: Se aplica el análisis cualitativo para generar gráficos e interpretar los resultados obtenidos en las encuestas y entrevistas desarrolladas en los departamentos a cargo de la administración de disertaciones de grado de la PUCE SD.
4.6. Metodología de desarrollo Para el
desarrollo de un software que se ajuste a la necesidad de los
usuarios, es primordial aplicar una
metodología que conduzca al
desarrollador de forma estructural y organizada, existen varias metodologías, que sirven de guía y comprenden las técnicas, procedimientos, herramientas y documentación necesarios a la hora de producir un software de calidad. Las metodologías agiles, se basan en la interacción entre los participantes en el proceso de software, como son los desarrolladores y el cliente; estas metodologías se caracterizan por establecer un proceso de desarrollo de manera parcial para ir evaluando y corrigiendo aspectos del sistema. 4.6.1. Programación Extrema “La Programación Extrema es una metodología de desarrollo de software que se basa en la simplicidad, la comunicación y la retroalimentación o reutilización del código desarrollado” (Fernández: 2002: 1).
38
La programación extrema se centra en el desarrollo de proyectos expuestos al constante cambio, es una metodología de desarrollo ágil, por ello busca la eficiencia en la construcción del sistema. Esta metodología consta de las siguientes fases: Análisis, Diseño, Implementación y Pruebas. Aplicación: Para el desarrollo del software de disertaciones de la PUCE SD se aplicó XP, al ser metodología liviana de desarrollo, permite
reducir
tiempo de iteraciones, promover la comunicación y el trabajo en equipo; además de garantizar un software de calidad centrado en los requerimientos del cliente. El intercambio continuo de información entre cliente-desarrollador hace que XP sea ideal para implementar una solución acertada que permita realizar múltiples cambios y prever mejor la ocurrencia de fallos durante las pruebas de aceptación. 4.6.1.1.
ANÁLISIS
4.6.1.1.1. Especificación de Requerimientos En este punto se redacta el documento de especificación de Requerimientos de software SRS, basado en el estándar IEEE 830, que contiene la siguiente estructura:
Introducción: Breve introducción del Documento de especificación de requerimientos, contiene lo siguiente:
Alcance: Lo que hará y no hará el sistema, límites y restricciones.
Glosario: Definición de términos, acrónimos y abreviaturas que se usan en el documento.
Actores: Se definen los Usuarios que interactúan con el Sistema.
39
En la sección de Especificación de Requisitos se registran los requisitos del sistema en forma detallada, se debe emplear un lenguaje entendible tanto para el desarrollador y el cliente. Los requisitos pueden clasificarse en los siguientes grupos:
Requisitos Funcionales: Estos son los requisitos que especifican la funcionalidad del Sistema, el desarrollo del mismo se enfoca en estos requisitos, es decir que estos requerimientos son los que reflejan el alcance del proyecto.
Requisitos No Funcionales: Son la especificación de aspectos externos al funcionamiento del programa, se basan en las herramientas y empleo de elementos que soportan el desempeño del software, como pueden ser: rendimiento,
seguridad,
fiabilidad,
disponibilidad,
Mantenibilidad,
Portabilidad.
Requerimientos de documentación: Tratan de la documentación que sustentara el mantenimiento y uso de la aplicación, por lo general se incluyen: manual de usuario, manual de instalación y
manual de
configuración del sistema.
Aplicación: Se analizaron los requerimientos obtenidos de los participantes en el proceso de Administración de disertaciones de grado de la PUCE SD y posterior se redactó el SRS para la elaboración del SADG, basado en el estándar IEEE 830,
en el que se especifica detalladamente el alcance,
limites, funcionalidad, aspectos de documentación, entre otros; que describen lo que contempla el sistema, ver Anexo 4. 4.6.1.1.2. Historias De Usuario Las historias de Usuario son redactadas en base a los requerimientos del cliente, en ellas se especifican ciertas características que contemplaran para su desarrollo. Se debe emplear un lenguaje comprensible en la redacción de las historias, el formato de una Historia de Usuario debe contener los siguientes aspectos:
40
Nombre de la Historia: Se da el nombre de la historia de usuario, debe ser lo más concreto posible.
Número de historia: Numerar las historias de Usuario en forma ascendente.
Días estimados: Se especifica los días que tomara el cumplimiento de cada historia, este valor puede estar propenso a cambios ya sea por retraso o cumplimiento previo de las mismas.
Prioridad: Se establece un valor de 1 a 3 para las historias, a mayor valor mayor prioridad.
Descripción: Se realiza una descripción más específica de lo que realizará cada historia de Usuario.
Aplicación: Las historias de Usuario son especificadas por el cliente, en el desarrollo
del
SADG,
estas
historias
son
la
traducción
que
los
desarrolladores realizan de los requerimientos obtenidos en las entrevistas a los participantes en la administración de disertaciones, ver Anexo 5. 4.6.1.1.3. Planificación de entregas
Tiempo Calendario
En la planificación de entregas, se define el tiempo calendario que cada integrante del equipo dedica al proyecto; se determinan las horas, días y semanas que se van a dedicar por cada integrante del equipo. Aplicación: El equipo de trabajo para el desarrollo del SADG estuvo integrado por dos personas, en la tabla 5 se determina el tiempo calendario que cada integrante dedico para la elaboración del proyecto, se registran las horas días y semanas que se dedicó por cada integrante para el desarrollo del proyecto.
41
Horas por dĂa
DĂas por semana Semanas por mes
5
5
4
Tabla 5: Tiempo Calendario Fuente: Los Autores.
ď&#x201A;ˇ
Esfuerzo de desarrollo
El esfuerzo que va a realizar
el equipo de desarrollo
determina las
semanas, horas y dĂas de esfuerzo que el equipo dedica al proyecto, se calcula de la siguiente manera: -
Horas de esfuerzo diarias nĂşmero de personas đ?&#x2018;&#x2039;
-
DĂas de esfuerzo semanal nĂşmero de personas đ?&#x2018;&#x2039;
-
đ?&#x2018;&#x203A;Ăşđ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;&#x153; đ?&#x2018;&#x2018;đ?&#x2018;&#x2019; â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x17D;đ?&#x2018;&#x2122; đ?&#x2018;&#x2018;Ăđ?&#x2018;&#x17D; = â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x2018;đ?&#x2018;&#x2019; đ?&#x2018;&#x2019;đ?&#x2018; đ?&#x2018;&#x201C;đ?&#x2018;˘đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;§đ?&#x2018;&#x153; đ?&#x2018;&#x2018;đ?&#x2018;&#x2013;đ?&#x2018;&#x17D;đ?&#x2018;&#x;đ?&#x2018;&#x2013;đ?&#x2018;&#x17D;đ?&#x2018; 1 đ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;
đ?&#x2018;&#x203A;Ăşđ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;&#x153; đ?&#x2018;&#x2018;đ?&#x2018;&#x2019; đ?&#x2018;&#x2018;Ăđ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x17D; đ?&#x2018;&#x2122;đ?&#x2018;&#x17D; đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D; = đ?&#x2018;&#x2018;Ăđ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x2018;đ?&#x2018;&#x2019; đ?&#x2018;&#x2019;đ?&#x2018; đ?&#x2018;&#x201C;đ?&#x2018;˘đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;§đ?&#x2018;&#x153; đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;đ?&#x2018;&#x2122; 1 đ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;
Semanas de esfuerzo mensual nĂşmero de personas đ?&#x2018;&#x2039;
4 đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x17D;đ?&#x2018;&#x2122; đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018; = đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x2018;đ?&#x2018;&#x2019; đ?&#x2018;&#x2019;đ?&#x2018; đ?&#x2018;&#x201C;đ?&#x2018;˘đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018;§đ?&#x2018;&#x153; đ?&#x2018;?đ?&#x2018;&#x153;đ?&#x2018;&#x; đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018; 1 đ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;
AplicaciĂłn: Se calculĂł el esfuerzo de desarrollo con los siguientes datos: - NĂşmero de horas de esfuerzo diarias por persona: 5 - DĂas de esfuerzo a la semana por persona: 5 - Semanas de esfuerzo mensual por persona: 4 - NĂşmero de personas: 2
42
ď&#x201A;ˇ
Horas de esfuerzo diarias. 2 personas đ?&#x2018;&#x2039;
ď&#x201A;ˇ
DĂas de esfuerzo semanal. 2 personas đ?&#x2018;&#x2039;
ď&#x201A;ˇ
5 đ?&#x2018;&#x2018;đ?&#x2018;&#x2013;đ?&#x2018;&#x17D;đ?&#x2018; = 10 đ?&#x2018;&#x2018;Ăđ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;?đ?&#x2018;&#x153;đ?&#x2018;&#x; đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D; 1 đ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;
Semanas de esfuerzo mensual. 2 personas đ?&#x2018;&#x2039;
ď&#x201A;ˇ
5 â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; = 10 â&#x201E;&#x17D;đ?&#x2018;&#x153;đ?&#x2018;&#x;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;&#x2018;đ?&#x2018;&#x2013;đ?&#x2018;&#x17D;đ?&#x2018;&#x;đ?&#x2018;&#x2013;đ?&#x2018;&#x17D;đ?&#x2018; 1 đ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;
4 đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;đ?&#x2018; = 8 đ?&#x2018; đ?&#x2018;&#x2019;đ?&#x2018;&#x161;đ?&#x2018;&#x17D;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;đ?&#x2018; đ?&#x2018;?đ?&#x2018;&#x153;đ?&#x2018;&#x; đ?&#x2018;&#x161;đ?&#x2018;&#x2019;đ?&#x2018; 1 đ?&#x2018;?đ?&#x2018;&#x2019;đ?&#x2018;&#x;đ?&#x2018; đ?&#x2018;&#x153;đ?&#x2018;&#x203A;đ?&#x2018;&#x17D;
EstimaciĂłn de historias de Usuario
DespuĂŠs de determinar el esfuerzo de desarrollo, se procede a estimar, el tiempo que tomarĂa el desarrollo de cada historia de Usuario, se agrupan en una tabla las historias por iteraciĂłn con su respectiva fecha de inicio y fecha de culminaciĂłn. Por lo general en la primera iteraciĂłn estĂĄn las historias de usuario de mayor prioridad; se establecen tres niveles de prioridad, el 1 es el mayor, 2 nivel intermedio y 3 es la prioridad mĂĄs baja. La estimaciĂłn de las historias de Usuario ayuda a determinar horas, dĂas y semanas de esfuerzo por cada historia de usuario, cabe indicar que una semana de desarrollo equivale a un punto. AplicaciĂłn: Las historias de usuario obtenidas segĂşn los requerimientos de la PUCE SD, fueron redactadas y clasificadas, se enumera cada historia y se establece una prioridad segĂşn el peso e importancia de la misma, los valores de mediciĂłn son: prioridad alta con valor de 1, media con valor de 2 y baja con un valor de 3.
43
Se agruparon las historias en tres iteraciones, se consideró la primera iteración para las prioridades más altas, de diseño y arquitectura de la aplicación. Cada historia tiene una estimación para su desarrollo, se asignó una duración entre uno y cuatro días según la historia y su alcance, como recomienda la metodología XP. Las semanas y horas se calcularon de acuerdo al esfuerzo de desarrollo obtenido, en conclusión al tener un equipo de desarrollo de dos personas cada semana contiene diez días de esfuerzo; así para calcular las semanas por historia se dividen los días estimados para diez. En el caso de horas se procedió multiplicando el número de días por diez, que es el tiempo calculado de desarrollo diario para el proyecto. 4.6.1.2.
DISEÑO
4.6.1.2.1. Diseño de la Base de Datos El Diseño de la base de datos se basa en el modelo Entidad- Relación, en este modelo se establecen las relaciones entre las entidades u objetos y sus atributos, cada objeto está contenido en registros mediante tablas. Aplicación: Para el modelado de datos del SADG, se utilizó Oracle SQL Developer Data Modeler, esta herramienta proporciona la capacidad de establecer relaciones de la Base de Datos definida en Oracle, lo que facilitó el diseño y la aplicación directa del modelo en la construcción de la aplicación, 4.6.1.2.2. Diseño de las tarjetas CRC Las tarjetas de CRC (Clase Responsabilidad Colaboración), sirven para el diseño de software; el empleo de estas tarjetas facilita la interpretación del desempeño de cada clase del sistema así como responsabilidades de cada clase.
la determinación de
44
El formato empleado en el desarrollo de software de las tarjetas CRC se basa en el esquema expuesto en la Figura 16, donde se registran el nombre de la clase, las responsabilidades que describen la funcionalidad de la misma y las clases que colaboran con la descrita.
Nombre de la Clase Responsabilidades
Colaboradores
Figura 16: Estructura tarjetas CRC. Fuente: Los Autores.
Aplicación: Las tarjetas CRC para el SADG se elaboraron posteriores al análisis del diseño del sistema, la clasificación de las clases del sistema se realiza por tipo controladores, entidades y servicio, ver Tabla 6. Clases Controladoras
Clases Entidades
Clases de Servicio
Controlador Usuario
Usuario
Servicio Sesión
Controlador Secretaria
Secretaria
Servicio CRUD Secretarias
Controlador Director
Estadística
Servicio FNSecretarias
Controlador Coordinador
Prorroga
Servicio Estadísticas
Controlador Estadísticas
Historial
Servicio Historial
Controlador Reporte
Actualización
Servicio Estudiantes
Controlador Resumen
Planes
Servicio Planes
Controlador Historial
Programas
Servicio Tutores
Controlador Reporte
Líneas Investigación Egresados Graduados
Tabla 6: Clasificación Clases del SADG. Fuente: Los Autores.
45
4.6.1.2.3. Diagrama de Clases El diagrama de clases de un software establece las acciones de cada clase en el sistema, se implementan, heredan y sobrecargan los
métodos y
funciones según el diseño lo requiera, este diagrama es parte fundamental para la comprensión de la estructura del programa. Aplicación: El diagrama de clases se elaboró luego del diseño de las tarjetas CRC, con un enfoque similar y tomando en cuenta las interacciones y relaciones de herencia y colaboración que realizan para definir la estructura y lógica del SADG. 4.6.1.2.4. Diseño Arquitectónico Para el diseño de la arquitectura de software se realiza la separación de los componentes por capas, se obtiene un modelo cliente servidor con la capa de datos, este modelo de diseño es uno de los más comunes en el desarrollo de aplicaciones de escritorio y orientadas a la web. Aplicación: El diseño del SADG, se realizó con la separación por capas, en la parte de cliente se incorporan los elementos que se relacionan con la presentación de la interfaz y elementos que interactúan con el usuario. La capa servidor contiene las clases que controlan y modelan los procesos que maneja el programa, además de los estilos empleados en la parte visual. Otra capa fundamental de la aplicación es la de datos que realiza las transacciones con el Gestor de Base de Datos Oracle. 4.6.1.2.5. Diseño de Interfaces En el desarrollo de software todo sistema requiere un diseño bien definido y funcional, esto se logra con una organización de los elementos del sitio, se definen el encabezado, menús, contenido, pie de página entre los puntos principales que una aplicación web requiere.
46
Aplicación: Para el diseño de las interfaces del SADG se tomó en cuenta aspectos visuales requeridos por el DICOM (Centro de Investigación de Diseño y Comunicación de la PUCE SD), donde se determinan los colores empleados en el sistema académico y la página web de la Universidad, tipo de fuente y logotipos de la Universidad. 4.6.1.2.6. Estructura jerárquica del Sistema
Figura 17: Estructura jerárquica del Sistema. Fuente: Los Autores.
4.6.1.3.
IMPLEMENTACION Y CODIFICACIÓN
4.6.1.3.1. Implementación de las iteraciones En la implementación de iteraciones se cumple con el desarrollo de las historias de usuario definidas en el análisis, esto se aplica de forma gradual conforme se va cumpliendo los objetivos planteados, en algunos casos las fechas que se estiman para la entrega de cada iteración son manipulables debido a los cambios que se presentan en la realización de pruebas y validaciones con el usuario.
47
Aplicación:
Primera Iteración En la primera iteración se aplicó el análisis inicial del sistema, se establece el modelo de la Base de datos, las tarjetas CRC, el diseño de las interfaces y el módulo de registro y autenticación de usuarios que ingresan al sistema SADG.
Segunda Iteración Esta iteración corresponde al desarrollo de los módulos de administración de usuarios, módulo de ingreso, módulo de asignación, módulo de resumen y registro de fechas de vencimiento de periodos de desarrollo de disertaciones.
Tercera Iteración El módulo de reportes se realizó en esta iteración, también se incluye la actualización de avances que registran para manejar el historial del proceso de elaboración del proyecto de disertación de grado.
Cuarta Iteración Las tareas pendientes de los módulos de asignación, registro y reportes se aplicaron en esta iteración, además de los cambios definidos en las iteraciones previas.
4.6.1.3.2. Seguimiento de las Iteraciones En el desarrollo de software es importante mantener un control del cumplimiento en los tiempos establecidos para la presentación de resultados, esas estimaciones pueden considerar el anticipo o retraso de cada entrega en algunos casos. Aplicación: En las tablas 7 a 10, se define como se desarrollaron las iteraciones, se registró el tiempo estimado para cada historia versus el tiempo real que tomó la implementación de cada una.
48
Si la historia se desarrolló con normalidad se acepta directamente en la iteración.
Si el tiempo de desarrollo supera al tiempo estimado se considera como Subestimado, el estado pasa a Pendiente y se resuelve en la siguiente iteración.
Si se desarrolló antes del tiempo estimado se considera como Sobrestimado y es Aceptado.
Historia de Usuario Diseño de la Base de Datos Diseño de tarjetas CRC Selección de herramientas de desarrollo Diseño de interfaces Autenticación de usuarios
Tiempo Estimado (días)
Tiempo Real (días)
Comparación de tiempos
Estado
3
5
Subestimado
Pendiente
2
2
3
2
4
5
Aceptada
3
3
Aceptada
Aceptada Sobrestimado
Aceptada
Tabla 7: Control de la Primera Iteración. Fuente: Los Autores.
Tiempo Estimado (días)
Tiempo Real (días)
Administración de usuarios
2
2
Ingreso Alumnos
1
3
Ingreso Directores de disertación
1
1
Ingreso Programa de disertación
2
1
Ingreso Plan de disertación
2
2
Ingreso Línea de investigación
2
1
Ingreso Período académico
1
1
2
1
Sobrestimado
Aceptada
3
2
Sobrestimado
Aceptada
3
3
Aceptada
3
3
Aceptada
Historia de Usuario
Asignación Plan de disertación de grado Asignación Director de disertación de grado Generación alertas para notificar vencimiento de período de disertación Registro de inicio período de
Comparación de tiempos
Estado Aceptada
Subestimado
Pendiente Aceptada
Sobrestimado
Aceptada Aceptada
Sobrestimado
Aceptada Aceptada
49
Prórroga Registro de inicio período de actualización de materias Registro de inicio período de actualización de materias
2
2
Aceptada
2
2
Aceptada
Tabla 8: Control de la Segunda Iteración Fuente: Los Autores.
Historia de Usuario Actualización avances de disertación de grado Reportes de Disertaciones por escuela Reportes de Disertaciones por estado de avance Reportes de Disertaciones por línea de investigación Reportes de Disertaciones por director Reportes de Disertaciones por vinculación a la comunidad Reportes de Disertaciones por tipo de financiamiento
Tiempo Estimado (días)
Tiempo Real (días)
2
2
2
3
Subestimado
Pendiente
2
3
Subestimado
Pendiente
3
3
Aceptada
2
2
Aceptada
1
1
Aceptada
2
1
Comparación de tiempos
Estado Aceptada
Sobrestimado
Aceptada
Tabla 9: Control de la Tercera Iteración. Fuente: Los Autores.
Historia de Usuario Asignación lectores de disertación escrita de grado Asignación miembros tribunal de defensa de disertación Registro de pagos de Prórroga Dar de baja a directores de disertación de grado Dar de baja a plan de disertación de grado Registrar graduación del estudiante Generar reporte de graduados de la PUCE SD Generar reporte de notas de disertación escrita de graduados de la PUCE SD Generar reporte de notas de defensa pública de las disertaciones de grado
Tiempo Estimado (días)
Tiempo Real (días)
Comparación de tiempos
Estado
3
2
Sobrestimado
Aceptada
3
2
Aceptada
3
2
Aceptada
1
1
Aceptada
1
2
Aceptada
1
1
2
3
Aceptada
1
1
Aceptada
2
2
Tabla 10: Control de la Cuarta Iteración. Fuente: Los Autores.
Sobrestimado
Sobrestimado
Aceptada
Aceptada
50
4.6.1.4.
PRUEBAS
4.6.1.4.1. Pruebas de Aceptación Las pruebas de aceptación se realizan luego de la entrega de cada iteración, para probar la funcionalidad del sistema y realizar las correcciones para la siguiente iteración en caso que se requiera. Cada historia de usuario requiere una prueba, misma que registra la siguiente información:
Precondiciones: Se registran las precondiciones para realizar cada prueba.
Entrada: Entrada de datos válidos e inválidos.
Resultado esperado 1: Resultado con datos válidos.
Resultado esperado 2: Resultado con datos no válidos.
Número de Prueba: Historia de usuario:
Precondiciones:
Entrada:
Resultado esperado 1:
Resultado esperado 2:
Tabla 11: Formato Pruebas de Aceptación. Fuente: www.extremeprogramming.org/
51
Aplicación: En la realización de las pruebas de aceptación para el SADG, se obtuvieron los casos de prueba para las historias de usuarios definidas en el análisis, no todas las historias de usuario permiten ejecutar pruebas de aceptación, algunas contemplan tareas de arquitectura mas no funcionalidad, como en el caso del diseño de la base de datos.
5.
RESULTADOS
5.1. Discusión y análisis de resultados. El DESARROLLO E IMPLEMENTACION DE UNA APLICACIÓN WEB PARA LA ADMINISTRACIÓN DE DISERTACIONES DE GRADO EN LA PUCE SD, fue propuesto con el fin de brindar acceso de una manera más práctica y eficaz a los participantes en el proceso de seguimiento y actualización de información, referente de las disertaciones de grado de la Universidad. Con la implementación del sistema se responde en tiempo real y de manera fiable las consultas por parte de Coordinadores de Investigación Aplicada III y IV, Directores de Escuela, Dirección Académica, Secretarias de Escuela; esto permite mantener al tanto de forma general a todas las escuelas de la PUCE SD, del estado real de sus disertaciones, propicia una mejor organización y la facultad de tomar decisiones. Se obtiene mayor seguridad y calidad de respuesta para el acceso a los registros e información, con una interfaz orientada a la web funcional, además se establecen perfiles de usuario para que puedan interactuar con el sistema según las necesidades y permisos respectivos para cada caso.
5.2. Análisis de requerimientos del SADG Los requerimientos para el desarrollo del sistema web para administración de disertaciones de grado de la PUCE SD, se obtuvieron en base a las entrevistas ejecutadas, en los distintos departamentos que administran las disertaciones de grado; con esta información se redactó el SRS, ver Anexo 4.A continuación se expone un resumen con la información obtenida de las entrevistas realizadas. 5.2.1. Entrevista aplicada a Directores de escuelas de la PUCE SD. ¿Cómo se lleva actualmente el control de las disertaciones de grado en las Escuelas?
52
53
Interpretación: El control se lo lleva mediante una matriz en excel, donde se registra la información relacionada a cada disertación de grado. ¿Qué tipo de información contiene dicha matriz que manejan en Excel? Interpretación: La matriz consta principalmente del tema de la disertación, programa al que pertenece dicha disertación, fecha de egresamiento, el o los alumnos que están en el proyecto de disertación, el director a cargo de la disertación de grado, el estado de avance en que se encuentra la disertación de grado mismo que comprende un estimado en porcentajes. ¿Quiénes están a cargo de registrar esa información en la matriz? Interpretación: La información de la matriz es registrada por las Secretarias de cada Escuela, a la vez se verifica por Dirección de Escuela. ¿Qué información considera más relevante de la matriz? Interpretación: La fecha de egresamiento, porque a partir de esa fecha el egresado tiene año y medio para el desarrollo de su disertación de grado, el programa de disertación en el cual se ingresó el proyecto, ya que este contiene un reglamento por el cual se rige. ¿Mencione otros aspectos que le gustaría tomar en cuenta para incluir en la matriz y justifique la razón? Interpretación: Manejar un historial, es decir temas que se han modificado, cambio de tutores, cambio de integrantes del proyecto, etc. Generar alerta previo el cumplimiento del plazo para desarrollo de la disertación de grado. 5.2.2. Entrevista aplicada en Dirección Académica de la PUCE SD. ¿Cómo se lleva actualmente el control de las disertaciones de grado en la PUCE SD?
54
Interpretación: El proceso de control de disertaciones de grado se lo procesa mediante una matriz elaborada en excel, allí se registra la información de cada proyecto, fecha de aprobación de tema, desarrolladores, director de la disertación de grado, fecha de egreso de los alumnos, programa al que pertenece la disertación escrita, estado de la disertación. ¿Cómo maneja toda esa información, teniendo en cuenta que están en diferentes escuelas? Interpretación: La información se la maneja por Escuela, cada Director presenta su informe acerca de avances, observaciones, etc. ¿Qué tipo de reportes o aspectos le gustaría generar con la información procesada para tomar decisiones? Reportes:
Por estudiante, para saber la situación de cada disertante.
Por tema, con el fin de conocer los participantes, estado, alcance, línea de
investigación de cada proyecto.
Por director de disertación, para revisar en detalle los proyectos que manejan los directores de disertaciones, se requiere un resumen semestral para analizar a cada uno.
Por escuela, para tener idea de la capacidad de proyectos de cada escuela, y analizar el flujo de graduados de cada una.
Por género, estos reportes nos permiten conocer el comportamiento académico de los estudiantes de nuestra Universidad según su género.
Por edad, para establecer una edad promedio de graduados.
Por notas, para conocer el promedio de notas de disertación escrita, defensa pública por alumnos.
55
Otros aspectos a considerar:
Es importante considerar la relación de cada proyecto a una determinada línea de investigación.
También se debe registrar la vinculación de los proyectos con la comunidad o en el caso de ser la misma Universidad, para saber a qué instituciones se beneficia con los proyectos de disertación.
Finalmente se requiere el tipo de financiamiento del proyecto de disertación de grado, si son medios propios, externos o patrocinados y en el caso de ser por la misma universidad, además se toma en cuenta la posibilidad de un financiamiento mixto.
5.2.3. Discusión de los resultados obtenidos en las entrevistas Con las entrevistas realizadas a los involucrados en la administración de disertaciones de grado, se señalaron los aspectos más relevantes acerca del proceso que se llevó a cabo sin automatización. Para el análisis de requerimientos del sistema, se especifica claramente los aspectos que son necesarios para brindar la solución adecuada con la implementación del SADG en la PUCE SD. 5.2.4. Encuesta dirigida a usuarios que participan en el proceso de administración de disertaciones de grado de la PUCE SD. 5.2.4.1.
Introducción
Se encuestó a los participantes en la administración de Disertaciones de cada Escuela de la PUCE SD, con el fin de analizar la percepción de los involucrados con el proceso actual. 5.2.4.2.
Determinación de la Población
Se determina la población con la siguiente información:
Entidad: Pontificia Universidad Católica del Ecuador sede Santo Domingo.
56
Actividad: Prestación de servicios de Grado, Postgrado y Formación Continua.
Ubicación: Vía a Chone Km. 2 y San Cristóbal, Santo Domingo de los Tsáchilas Ecuador.
Área: Administración de Disertaciones de Grado.
Población: Participantes del proceso de administración de Disertaciones de Grado los departamentos de Secretarias, Dirección de Escuela, Dirección Académica, Coordinación de Investigación Aplicada, en total 18.
Muestra: La muestra es igual a la población, al contar con una población menor a 30 individuos se considera el total de 18 participantes.
5.2.4.3.
Tabulación de los datos
Pregunta 1 ¿Considera usted que el actual proceso para administración de disertaciones de grado es eficiente?
Alternativas
Cantidad
Porcentaje
SI
3
17%
NO
15
83%
Total
18
100%
Tabla 12: Tabulación de datos obtenidos en la pregunta 1. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
57
Pregunta 1.1 Si la respuesta en la pregunta 1 es “no”, ¿indique el grado de deficiencia que considera que tiene el actual proceso de administración disertaciones de grado?
Alternativas
Cantidad
Porcentaje
Poco Deficiente
5
28%
Deficiente
9
50%
Muy Deficiente
1
5%
TOTAL
15
83%
Tabla 13 : Tabulación de datos obtenidos en la pregunta 1.1. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
Poco Deficiente
Deficiente
Muy Deficiente
28% SI 17%
NO 83% 50% 5%
Gráfico 1: Representación porcentual de datos de la pregunta 1. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
58
Interpretación: En la Tabla 12, el 83% considera que el actual proceso de administración de disertaciones de grado no es eficiente, mientras el 17% consideran que el proceso si es eficiente. Análisis: Los resultados indican que el proceso es deficiente, por lo que se concluye que existen fallas en el proceso de administración de disertaciones de grado. Pregunta 2 ¿Qué tiempo estima que toma realizar un reporte completo de disertaciones de grado por estudiante?
Alternativas
Cantidad
Porcentaje
Horas
4
22%
Días
12
67%
Semanas
2
11%
TOTAL
18
100%
Tabla 14: Tabulación de datos obtenidos en la pregunta 2. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD
11%
22% Horas Días Semanas 67%
. Gráfico 2: Representación porcentual de datos de la pregunta 2. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
59
Interpretación: En la Tabla 14 el 67% considera que el actual proceso de administración de disertaciones de grado tarda días en generar un reporte completo por alumno, el 22% estima que un reporte tarda horas, mientras el 11% considera que el proceso de reporte por alumno tarda semanas. Análisis: Los resultados muestran que el proceso tarda días, para generar un reporte completo de disertación de grado por alumno. Pregunta 3 ¿La información que se obtiene con el proceso actual en cuanto a las disertaciones de grado en las Secretarias de Escuela y Dirección Académica es?
Alternativas
Cantidad
Porcentaje
Precisa
9
60%
Incoherente
1
7%
Inconsistente
5
33%
TOTAL
15
100%
Tabla 15: Tabulación de datos obtenidos en la pregunta 3. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
60
33%
Precisa Incoherente Inconsistente
60% 7%
Gráfico 3: Representación porcentual de datos de la pregunta 3. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
Interpretación: En la Tabla 15 el 60% considera que el actual proceso de administración de disertaciones de grado maneja información precisa, el 33% afirma que el proceso trabaja con información inconsistente, mientras el 7% considera que la información es incoherente. Análisis: Los resultados indican que el proceso maneja información precisa, aunque pueden presentarse inconsistencias e incoherencias muy pocas veces. Pregunta 4 ¿La actual administración de las disertaciones de grado tiene procesos automatizados? Alternativas
Cantidad
Porcentaje
SI
0
0%
NO
18
100%
Total
18
100%
Tabla 16: Tabulación de datos obtenidos en la pregunta 4. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
61
Pregunta 4.1 Si la respuesta en la pregunta 4 es “no”, ¿indique el grado de importancia que tendría administrar las disertaciones de grado en forma automática?
Alternativas
Cantidad
Porcentaje
Poco Importante
0
0%
Importante
3
17%
Muy Importante
15
83%
TOTAL
18
100%
Tabla 17: Tabulación de datos obtenidos en la pregunta 4.1. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
Poco Importante
Importante
Muy Importante
0% 17%
NO 100%
83%
Gráfico 4: Representación porcentual de datos de la pregunta 4. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
62
Interpretación: En la Tabla 16, el 100% indica que el actual proceso de administración de disertaciones de grado no está automatizado y para el 83%, ver Tabla 17, es muy importante que se lo automatice. Análisis: Los resultados muestran que la administración de disertaciones de grado no tiene procesos automatizados. Pregunta 5 ¿La actual administración de las disertaciones de grado contiene un historial de seguimiento actualizado y centralizado?
Alternativas
Cantidad
Porcentaje
SI
9
50%
NO
9
50%
Total
18
100%
Tabla 18: Tabulación de datos obtenidos en la pregunta 4. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
50% 50%
SI NO
Gráfico 5: Representación porcentual de datos de la pregunta 5. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
63
Interpretación: En la Tabla 18 el 50% indica que el actual proceso de administración de disertaciones de grado contiene un historial de seguimiento actualizado y centralizado, mientras el otro 50% indica que el proceso no contiene un historial de seguimiento actualizado y centralizado. Análisis: Los resultados muestran que la mitad del personal considera que existe un historial de seguimiento actualizado y centralizado, sin embargo, este historial no es efectivo para el otro 50% de los encuestados. Pregunta 6 ¿Estaría usted dispuesto a manejar una plataforma en entorno Web para administración de las disertaciones de grado?
Alternativas
Cantidad
Porcentaje
SI
17
94%
NO
1
6%
Total
18
100%
Tabla 19: Tabulación de datos obtenidos en la pregunta 6.
Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD
Pregunta 6.1 Si la respuesta en la pregunta 6 es “si”, ¿indique el grado de complejidad que tendría
usted para manejar una aplicación en entorno Web en el
proceso de administración de disertaciones de grado?
Alternativas
Cantidad
Porcentaje
Poco Complejo
15
83%
Complejo
2
11%
64
Muy Complejo
0
0%
TOTAL
17
94%
Tabla 20: Tabulación de datos obtenidos en la pregunta 6.1. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD
Poco Complejo
NO 6%
Complejo
SI 94%
Muy Complejo
83%
11% 0%
Gráfico 6: Representación porcentual de datos de la pregunta 6. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
Interpretación: En la Tabla 19 el 94% afirman que si estarían dispuestos a manejar una plataforma en entorno Web para administración de las disertaciones de grado, mientras el 6% indica que no estarían dispuestos a hacerlo. Se puede apreciar también que un 83% considera poco complejo el uso de una aplicación en entorno web, para el manejo del proceso, ver Tabla 20. Análisis: Los resultados indican que los participantes en el proceso de administración de disertaciones de grado en su gran mayoría están dispuestos a manejar una plataforma en entorno web debido a que lo consideran poco complejo.
65
Pregunta 7 ¿Cree usted que un sistema informático ayudaría a mejorar el proceso de administración de disertaciones de grado?
Alternativas
Cantidad
Porcentaje
SI
17
100%
NO
0
0%
Total
17
100%
Tabla 21: Tabulación de datos obtenidos en la pregunta 7. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
0%
SI NO
100%
Gráfico 7: Representación porcentual de datos de la pregunta 7. Fuente: Participantes en el proceso de administración de disertaciones de grado de la PUCE SD.
Interpretación: En la Tabla 21 el 100% afirman que un sistema informático ayudaría a mejorar el proceso de administración de disertaciones de grado. Análisis: Los resultados concluyen que el sistema informático es una solución para mejorar el proceso de grado.
administración de disertaciones de
66
5.2.4.4.
Discusión de los resultados obtenidos en la Encuesta
Los resultados obtenidos en la encuesta expusieron claramente la necesidad de automatizar los procesos que se llevan a cabo en la PUCE SD, para la administración de disertaciones de Grado, el desarrollo e implementación del SADG fue la decisión que se tomó, para dar solución a los inconvenientes presentes en los departamentos que fueron encuestados. 5.2.5. Identificación de Historias De Usuario Como resultado de las entrevistas y los requerimientos especificados en el SRS para el desarrollo del SADG, se obtuvieron las historias de Usuario, las cuales se agruparon en varias iteraciones para programar su fecha de entrega como se detalla en la etapa de división de iteraciones. 5.2.6. Plan de entregas El proyecto se dividió en iteraciones agrupando las historias de usuario, ver Tabla 22; se programaron períodos de desarrollo para la entrega de cada iteración en forma periódica, con el fin de mantener un ritmo equilibrado de desarrollo. El esfuerzo estimado se calculó mediante: Horas: Total de horas dedicadas por el equipo para cada Historia de Usuario. Días: Se obtiene dividiendo el número horas para las horas calculadas de esfuerzo por equipo (# horas /10). Semanas: Es el resultado de la división de los días que toma la historia dividido para el número de días de esfuerzo semanal que dedica el equipo, cada miembro dedica 5 horas que da un total de 10 (# días/10).
67
Historia No.
Iteraci贸n No.
Prioridad
Fecha Inicio
Fecha Fin
Esfuerzo/ Calendario estimado semanas
d铆as
horas
1
1
1
29/05/2013
31/05/2013
0,3
3
30
2
1
1
31/05/2013
01/06/2013
0,2
2
20
3
1
1
01/06/2013
03/06/2013
0,3
3
30
4
1
3
03/06/2013
06/06/2013
0,4
4
40
5
1
1
06/06/2013
08/06/2013
0,3
3
30
6
2
2
08/06/2013
09/06/2013
0,2
2
20
7
2
1
09/06/2013
09/06/2013
0,1
1
10
8
2
1
10/06/2013
10/06/2013
0,1
1
10
9
2
1
10/06/2013
11/06/2013
0,2
2
20
10
2
1
11/06/2013
12/06/2013
0,2
2
20
11
2
1
12/06/2013
13/06/2013
0,2
2
20
12
2
1
13/06/2013
13/06/2013
0,1
1
10
13
2
1
13/06/2013
14/06/2013
0,2
2
20
14
2
1
14/06/2013
16/06/2013
0,3
3
30
15
3
1
16/06/2013
17/06/2013
0,2
2
20
16
4
2
17/06/2013
19/06/2013
0,3
3
30
17
4
2
19/06/2013
21/06/2013
0,3
3
30
18
2
1
21/06/2013
23/06/2013
0,3
3
30
19
2
1
23/06/2013
25/06/2013
0,3
3
30
20
4
2
25/06/2013
27/06/2013
0,3
3
30
21
2
2
27/06/2013
28/06/2013
0,2
2
20
22
3
1
28/06/2013
29/06/2013
0,2
2
20
23
3
2
29/06/2013
30/06/2013
0,2
2
20
24
3
1
30/06/2013
02/07/2013
0,3
3
30
25
3
1
02/07/2013
03/07/2013
0,2
2
20
26
3
1
03/07/2013
03/07/2013
0,1
1
10
27
3
2
04/07/2013
05/07/2013
0,2
2
20
28
4
3
05/07/2013
05/07/2013
0,1
1
10
29
4
3
06/07/2013
06/07/2013
0,1
1
10
30
4
2
07/07/2013
07/07/2013
0,1
1
10
31
4
1
07/07/2013
08/07/2013
0,2
2
20
32
4
2
09/07/2013
09/07/2013
0,1
1
10
33
4
2
09/07/2013
10/07/2013
0,2
2
20
Tabla 22: Estimaci贸n de historias de usuario para el SADG. Fuente: Los Autores.
68
5.3. Diseño del Sistema de Administración de disertaciones de grado en base a los requerimientos 5.3.1. Diseño Conceptual En el Diseño conceptual se obtuvo el Modelo Entidad- Relación de la Base de datos que soportará las transacciones del SADG, ver Figura 18.
Figura 18: Diseño de BDD de SADG. Fuente: Los Autores.
69
El modelo está compuesto por las tablas, identificadas con una clave principal, y relacionadas según su correspondencia en el diseño; también se incluyeron las tablas del sistema académico actual de la PUCE SD, para obtener registros de estudiantes, docentes, materias y escuelas. 5.3.2. Tarjetas CRC Las tarjetas CRC se registran con el tipo de clase que se implementaron, ver Anexo 6. Para las estadísticas del SADG, el controlador Estadística, utiliza los métodos de consulta e impresión de las estadísticas, que el usuario requiere, ver Tabla 23. La entidad se encarga de enviar el tipo de consulta que se realiza para el cálculo, ver Tabla 24; mientras el servicio se encarga de la conexión y consulta en la base de datos, para dar respuesta a la petición de la entidad Estadística.
Controlador Estadística Consulta tipo estadística
Estadística
Imprime estadística
Estadística
Tabla 23: Tarjeta CRC Controlador Estadística. Fuente: Los Autores.
Estadística
Enviar Consulta
Controlador estadística
Devolver estadística
Servicio estadística
Tabla 24: Tarjeta CRC entidad Estadística. Fuente: Los Autores.
70
5.3.3. Diagrama de Clases SADG El diagrama de clases para el SADG se desarrolló con herramientas UML, para mantener un estándar de diseño en arquitectura de software. Ver Figura 19.
Figura 19: Diagrama de Clases del SADG. Fuente: Los Autores.
71
5.3.4. Diseño arquitectónico del SADG La figura 20 ilustra
el la estructura de las capas, con las tecnologías
empleadas en el diseño arquitectónico para el desarrollo del sistema.
Figura 20: Diseño arquitectónico SADG. Fuente: Los Autores.
72
5.3.5. Diseño de Interfaces del SADG. El diseño de interfaz para cada módulo de aplicación se obtuvo con los requerimientos de diseño del DICOM, manteniendo un aspecto formal y la organización estructural de los contenidos de la aplicación web. 5.3.5.1.
Formulario de Ingreso al sistema
En el formulario de ingreso al sistema se especifica el Nombre de Usuario y Contraseña, para iniciar sesión, ver Figura 21.
Figura 21: Ingreso al Sistema. Fuente: Los Autores.
5.3.5.2.
Formulario Principal Secretarias
El formulario de Secretarias General, ver Figura 22, contiene un menú dinámico y sencillo para garantizar el trabajo eficiente de los usuarios en el registro y actualización de datos al sistema. Con el Patrón SPI se evita el uso de botones siguiente y anterior y la navegación se vuelve más dinámica, para cada elemento de la página principal se ejecuta una ventana modal, asi se evita recargar la misma mientras se trabaja con la información de Estudiantes, Directores de Disertación, Temas de Disertación, etc.
73
Para las Secretarias de cada Escuela la estructura es similar, con la diferencia que el acceso a los registros está filtrado por Escuelas.
Figura 22: Inicio Secretaria General. Fuente: Los Autores.
Formulario Administración de Estudiantes
Figura 23: Administración Estudiantes. Fuente: Los Autores.
74
Formulario Administración de Temas de Disertación de Grado
Figura 24: Administración Temas de Disertación Fuente: Los Autores
5.3.5.3.
Formulario Principal Directores
La interfaz para los Directores maneja una estructura SPI, con acceso a gráficos estadísticos a través de PopUps, se visualizan las animaciones gracias a la implementación de Highcharts, que brindan un aspecto visual más dinámico y útil para la interpretación de la información que requieren los Directores. La interfaz de Directores de Escuela y General mantienen una estructura similar, solo se filtran los datos por escuela y en el caso de Dirección Académica se brinda acceso a la información de todas las carreras. 5.3.6. Discusión de los resultados obtenidos en el diseño del SADG En base a los diseños desarrollados, se concluyó la parte estructural del sistema, gracias al modelado de datos, diagrama de clases y otros aspectos fundamentales para la arquitectura y funcionalidad del proyecto.
75
5.4. Codificación e Implementación del SADG. 5.4.1. Codificación La codificación se realizó en la herramienta Netbeans para un desarrollo efectivo del aplicativo web, en esta sección se exponen las clases, modelos, vistas y controladores principales del SADG, debido a la magnitud del código completo disponible en el CD_SADG adjunto como anexo al proyecto. La figura 25 ilustra las librerías que se emplearon en JavaScript para la aplicación web.
Figura 25: Código de librerías y recursos externos. Fuente: Los Autores.
El manejo de menú se lo realizo con un enfoque interactivo, para mejorar el aspecto visual y funcional de la página, se utiliza una función de cargar menú para determinar la opción que el usuario selecciona. En la figura 26 se define la estructura que controla el elemento que se va a desplegar con una variable de control que el usuario manipula según lo requiera.
76
Figura 26: C贸digo de control de men煤 principal. Fuente: Los Autores.
La figura 27 muestra el c贸digo empleado para la manipulaci贸n de la lista que se carga en el JQgrid.
77
Figura 27: Código lista de alumnos. Fuente: Los Autores.
El control de gráficos estadísticos con las librerías de Highcharts se ilustra en la figura 28, se configuran las opciones del gráfico y manipulan las cadenas Strings que van a imprimirse.
78
Figura 28: Código resumen estadísticas Highcharts. Fuente: Los Autores.
EL manejo de sesiones se lo realiza con la clase Login, ver Figura 29. Se verifica el usuario y contraseña, en caso de entradas invalidas se presenta el mensaje de error, también se controla el acceso a los módulos designados para cada perfil.
79
Figura 29: C贸digo clase Login, Ingreso al Sistema. Fuente: Los Autores.
Las hojas de estilo, esenciales para el control y posicionamiento de los objetos HTML 5, se exponen en la Figura 30.
Figura 30: C贸digo dise帽o CSS. Fuente: Los Autores.
80
El uso del patrón Singleton que sirve para instanciar una sola vez la conexión se expone en la Figura 31.
Figura 31: Código patrón Singleton. Fuente: Los Autores.
5.4.2. Implementación de Iteraciones La entrega e implementación de iteraciones se realizó en coordinación con el departamento de Planificación de la PUCE SD, se obtuvieron las actas como resultado y constancia de las entregas, ver Anexo 7. 5.4.3. Discusión de los resultados obtenidos en la codificación e implementación. Se desarrolló e implemento el proyecto en función de los requerimientos, en cada iteración surgieron cambios que se contemplaron en la planificación del desarrollo del SADG, al usar XP como metodología se facilitó la realización de estas correcciones.
81
5.5. Pruebas 5.5.1. Pruebas de Aceptación En las tablas 25 y 26 se plasma la realización de dos casos de pruebas de aceptación. Se ejecutaron las pruebas de acuerdo a la funcionalidad de cada historia de usuario, el resto de pruebas se incluyen en anexos, ver Anexo 8.
Número de Prueba: 18 Historia de usuario: Generar reporte de disertaciones por tipo vinculación a la comunidad.
Precondiciones: Tener asignado perfil de secretaría-director-coordinador.
Entrada: El usuario ingresa nombre de usuario y contraseña. El usuario escoge el menú generar reporte de disertaciones por tipo vinculación con la comunidad.
Resultado esperado 1: El sistema verifica si el usuario y contraseña son correctos. El sistema permite acceso al módulo de reportes. El sistema despliega el reporte de disertaciones por tipo de vinculación con la comunidad.
Resultado esperado 2: El sistema verifica usuario y contraseña incorrectos. El sistema muestra mensaje "Nombre de usuario o contraseña incorrectos". El sistema no permite el acceso al módulo de reportes.
Tabla 25: Prueba de aceptación Generar reporte de disertaciones por tipo vinculación a la comunidad. Fuente: Los autores.
82
Número de Prueba: 1 Historia de usuario: Autenticación de Usuarios. Precondiciones: Tener Tener asignado un perfil.
asignado
un
usuario,
contraseña.
Entrada: El usuario ingresa su Nombre de usuario y contraseña.
Resultado esperado 1: El sistema verifica si el usuario y contraseña son correctos. El sistema permite el ingreso de usuario al módulo que corresponde. Resultado esperado 2: El sistema verifica usuario y contraseña incorrectos. El sistema muestra mensaje "Nombre de usuario o contraseña incorrectos". Tabla 26: Prueba de aceptación Autenticación de Usuarios. Fuente: Los autores.
5.5.2. Discusión de los resultados obtenidos en las pruebas Las pruebas de aceptación realizadas sirvieron para determinar los eventos y resultados que se obtienen con entradas válidas y no válidas al sistema, se comprobó la secuencia que sigue la realización de las actividades generadas por las historias de usuario, finalmente se realizó la entrega formal del sistema, con el acta de entrega - recepción, ver Anexo 9, donde se incluyeron los siguientes elementos:
Código fuente aplicación e instaladores (CD).
Manual de usuario, ver Anexo 10.
Manual de Instalación y configuración, Ver Anexo 11.
CONCLUSIONES
La Metodología XP, se enfoca en el desarrollo de aplicaciones que buscan la satisfacción del cliente y
expuestas al cambio constante
mediante la retroalimentación.
En cuanto a seguridad, el SADG proporciona la encriptación de claves de acceso, la codificación de caracteres UTF8 es otra ventaja de la programación web, y con la implementación del modelo DAO (Data Access Object) se evita ataque de hackers a través de comandos SQL más conocido como SQL Injection.
Son múltiples las ventajas de desarrollar e implementar aplicaciones Web, como el fácil acceso, es decir en forma remota; además de no requerir la instalación de aplicaciones de escritorio en los equipos cliente siempre que cuenten con un navegador compatible y una conexión de red confiable.
El
uso de herramientas Open Source, permite mantener vigente el
sistema que se desarrolló en el entorno IDE Netbeans licencia GPL 2.0, al ser código libre y modificable, se deja la apertura de actualización y escalabilidad a futuro.
Los gráficos estadísticas empleadas en el proyecto permiten, dar valor agregado a la aplicación a nivel de presentación, esto apoya la innovación tecnológica que propone el SADG en su implementación en la PUCE SD.
Actualmente las instituciones requieren el uso de tecnología informática para soportar todos sus procesos, administrando de manera eficiente sus transacciones y el procesamiento de información automática.
83
en forma
84
La comunicación entre el
equipo de trabajo y el cliente es de vital
importancia, para la obtención de un software que además de cumplir con los requerimientos brinde la calidad necesaria, al poner de manifiesto las ideas de todo el equipo en cada etapa de desarrollo de los procesos que requieran mejorar o adaptarse al sistema.
Mediante la división en iteraciones que XP establece en el desarrollo de software, se facilita el análisis y programación de los módulos requeridos por el usuario, así como el trabajo de detección y corrección de errores.
LÍMITES Y RECOMENDACIONES
Elegir una metodología de desarrollo de software acorde al sistema que se va a desarrollar, para ello se deben analizar todos los aspectos relevantes que requiere la aplicación, como son: alcance, recursos disponibles, costos, tiempo de desarrollo, etc.
La calidad de todo proyecto depende del equipo de desarrollo, es por ello que se recomienda elegir y asignar
responsabilidades a los
integrantes del equipo según el perfil y ámbito en el que mejor se desenvuelven.
Las metodologías de investigación como las de desarrollo de software, son el eje fundamental para guiar el desarrollo de un proyecto de disertación de grado, sin embargo, es importante tomar en cuenta que cada caso de estudio contiene particularidades, que pueden extraer o incorporar técnicas e instrumentos ajenos a la metodología.
Realizar las pruebas considerando todos los casos posibles de ocurrencia, al desarrollar un sistema con XP, ya sea de escritorio u orientada a la web, ya que el cambio constante
exige al equipo de
trabajo en conjunto con el cliente que deban realizar un análisis exhaustivo de las posibilidades al modificar el diseño inicial.
Orientar el trabajo de desarrollo de un sistema, a la satisfacción del cliente, ya que, muchas veces se fija como objetivo el cumplimiento de los requerimientos, dejando de lado la calidad e innovación que debe incluir un software.
Revisar los manuales de usuario, para solventar cualquier duda sobre el uso de la aplicación y su funcionamiento, de igual manera para la instalación y configuración del sistema, es indispensable que el administrador conozca la configuración correcta del mismo. 85
86
REFERENCIAS Referencias Bibliográficas Barney. (2008). Oracle Db Ajax & Php Web Appl. India: Mc Graw Hill-Education. Beck, K. & Fowler, M. (2000). Planning Extreme Programming. USA: AddisonWesley. Camps Paré, R. (2002). Introducción a Base de Datos. España: UOC. Doyle, M. (2010). Php Práctico. España. Anaya Multimedia. Fernández, G. (2002). Introducción a Extreme Programming. Málaga España. SE Hernández Sampieri, R., Fernández Collado, C. & Baptista Lucio, C. (2010). Metodología de la Investigación. Ciudad de México, México: Mc Graw Hill. Llanos Ferraris, D. (2010). Fundamentos de informática y programación en C. Madrid, España: Paraninfo. Martínez Usero, J & Lara Navarra, P. (2007). La Producción de Contenidos Web. Barcelona, España: UOC. Muñoz Razo, C. (2011). Como elaborar y asesorar una Investigación de Tesis. Ciudad de México, México: Pearson Educación. Posso Yépez, M. (2009). Metodología para el Trabajo de Grado. Ibarra, Ecuador: NINA. Romero Granados, S. (2007). Introducción temprana a las TIC. España: ESTILO ESTUGRAF. Sabino, C. (2000). El proceso de Investigación. Caracas, Venezuela: Panapo.
87
Referencias Lincográficas Arranz Santamaría, J. (2011). The Single Page Interface Manifesto. Recuperado de http://itsnat.sourceforge.net/php/spim/spi_manifesto_es.php Cake Software Foundation, Inc. (2014). Entendiendo el Modelo – Vista – Controlador. Recuperado de http://book.cakephp.org/2.0/es/cakephpoverview/understanding-model-view-controller.html Classora (2009). Ranking de las mejores Bases de Datos Actuales. Recuperado de http://es.classora.com/reports/x46901/graphics/ranking-de-las-mejores-bases-dedatos-actuales Eguíluz, J. (2008). Introducción a AJAX. Recuperado de http://librosweb.es/ajax/ Eguíluz, J. (2009). Introducción a CSS. Recuperado de http://librosweb.es/css/ Eguíluz, J. (2008). Introducción a JavaScript. Recuperado de http://librosweb.es/javascript/ Joskowicz, J. (2008). Reglas y Prácticas en extreme Programming. Recuperado de http://pis.unicauca.edu.co/moodle/mod/resource/view.php?id=30185 Pozo, J. (2001). Especificación del Modelo de Objetos del Documento (DOM), Nivel 1. Recuperado de http://html.conclase.net/w3c/dom1-es/introduction.html
88
GLOSARIO AJAX JavaScript asíncrono y XML, técnica de desarrollo web que ejecuta las instrucciones de los usuarios de manera ágil e interactiva, mientras realiza las transacciones de datos con el servidor en segundo plano. CSS Hojas de estilo en cascada, mecanismo de diseño para definir el estilo de los elementos de una página web. DAO Objetos de Acceso a Datos, permiten manipular las bases de datos mediante objetos para acceder a la información de manera abstracta y utilizar los métodos de una clase en forma transparente. FRAMEWORK Marco de Trabajo, estructura o módulos integrados que permiten el desarrollo de software de manera integrada y organizada. GPL Licencia Publica General, es la licencia que permite la utilización y modificación de código de software en forma libre. HTML Es un lenguaje para desarrollar páginas web , que permite presentar texto, imágenes, archivos y todo el contenido que utilizamos en un sitio. IDE Entorno Integrado de desarrollo del inglés Integrated Development Environment, conjunto de herramientas integradas para desarrollar programas informáticos.
89
JAVA SCRIPT Lenguaje de programación, que se utiliza en páginas web para un diseño y e interacción en forma más dinámica. JQUERY Biblioteca de Java Script, que maneja eventos y contenido web integrando Ajax. JRE Entorno de Ejecución Java, permite la ejecución de aplicaciones java en distintos sistemas operativos. JUNIT Conjunto de librerías de Java que sirven para realizar pruebas en la utilización de clases. MD5 Algoritmo de encriptación de datos, basado en el cifrado para transformar cadenas de texto a números de 128 bits. MVC Modelo Vista Controlador, patrón o modelo de programación que consiste en separación del código por capas, para una programación bien estructurada y de fácil configuración. Las tres capas que propone este patrón son: el modelo del negocio, la vista o presentación, y controlador que responde a los eventos e invoca al modelo. PHP Lenguaje de programación para el uso de contenido y transacciones web en forma dinámica. PLUGINS En informática es una aplicación que amplía las funciones de cierto programa, un complemento. RESULTSETS Cadena que se obtiene de una consulta
90
SRS Especificación de requerimientos de Software, documento que contiene todos los requerimientos que tiene un programa. Tarjetas CRC Tarjetas Clase, responsabilidad Colaboración: Método para diseño de software, basado en el desarrollo orientado a objetos, estas tarjetas registran el trabajo que realizan las clases y determina los responsables o colaboradores de las mismas. UML Lenguaje Unificado de Modelado, permite construir y presentar un modelado de la estructura que tiene un software, mediante el uso de diagramas. UTF8 Formato de codificación de caracteres, generalmente utilizado en páginas web y correos electrónicos. XML Lenguaje de manipulación de información estructurada, que permite las transacciones y comunicación de varias aplicaciones en forma integrada. XP Programación Extrema (XP), metodología de desarrollo ágil de software basada en la simplicidad, comunicación, retroalimentación, adaptabilidad y orientada a cumplir los requerimientos y satisfacción del cliente.