diseÑo e implementaciÓn de un mÓdulo de administraciÓn de
TRANSCRIPT
DISEÑO E IMPLEMENTACIÓN DE UN MÓDULO DE ADMINISTRACIÓN DE USUARIOS Y DISEÑO DE UN ALGORITMO DE ENCOLAMIENTO PARA
INTEGRARSE AL PROYECTO U2-ROUTE
MÓNICA ALEJANDRA NARANJO BETANCUR
JULIAN DUQUE MEJIA
DANIEL FELIPE RIOS GONZÁLEZ
UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BASICAS E INGENIERIA
PEREIRA 2011
2
DISEÑO E IMPLEMENTACIÓN DE UN MÓDULO DE ADMINISTRACIÓN DE USUARIOS Y DISEÑO DE UN ALGORITMO DE ENCOLAMIENTO PARA
INTEGRARSE AL PROYECTO U2-ROUTE
MONICA ALEJANDRA NARANJO BETANCUR JULIAN DUQUE MEJIA
DANIEL FELIPE RIOS GONZÁLEZ
TRABAJO PRESENTADO PARA OPTAR ALTÍTULO DE INGENIEROS DE SISTEMAS Y
TELECOMUNICACIONES
DIRECTOR: MSC. ALVARO IGNACIO MORALES
UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BASICAS E INGENIERIA
PEREIRA 2011
3
….A nuestros padres y familiares por su constante apoyo, por brindarnos moral para seguir adelante a pesar
de los inconvenientes y alentarnos a salir adelante.
4
AGRADECIMIENTOS
La realización del actual proyecto de grado requirió de múltiples sacrificios y
tiempo, que hoy que se ven gratificados con la culminación del proceso. Este
proyecto no se habría podido terminar si la colaboración de nuestros asesores,
maestros y demás personas a quienes expresamos nuestro agradecimiento por su
constante disposición a la hora de resolver nuestras dudas y orientarnos.
Hoy finalmente se ven cumplidos propósitos, anhelos, sueños y metas durante la
carrera, adquirimos conocimiento, ganamos experiencia, y vencimos muchos de
los miedos que teníamos y aún nos quedan muchas ganas de continuar el camino
que solo apenas comienza con la finalización de este proyecto.
Queremos agradecer muy especialmente al Ingeniero Jhonattan Córdoba por su
apoyo en nuestras decisiones y críticas constructivas en el momento de la
construcción de los módulos, por el soporte ante los obstáculos y ayuda para
sortearlos. A los Ingenieros Álvaro Ignacio Morales y Luis Eduardo Peláez,
docentes de la facultad de Ciencias Básicas e Ingeniería, por brindarnos asesoría,
orientación constante y oportuna durante el desarrollo de la documentación del
proyecto
Y por último y no por importancia, a Dios por brindarnos la oportunidad de conocer grandes mentores a lo largo de nuestro proceso de formación académica, a nuestra familia que siempre nos apoya con nuestras metas a cumplir y a nuestros grandes compañeros por los buenos momentos.
Por los motivos mencionados mil gracias.
Mónica Alejandra Naranjo Betancur Daniel Felipe Ríos González
Julián Duque Mejía
5
CONTENIDO
LISTA DE FIGURAS ........................................................................................................................ 8
LISTA DE TABLAS ......................................................................................................................... 10
LISTA DE ANEXOS ....................................................................................................................... 11
RESUMEN ....................................................................................................................................... 12
GLOSARIO ...................................................................................................................................... 13
INTRODUCCIÓN ............................................................................................................................ 17
1. OBJETIVOS ............................................................................................................................ 19
1.1. OBJETIVO GENERAL ................................................................................................... 19
1.2. OBJETIVOS ESPECÍFICOS ........................................................................................ 19
2. MARCO TEÓRICO ................................................................................................................. 20
2.1. PAPEL DE LA INGENIERÍA DE SOFTWARE ........................................................... 20
2.2. METODOLOGÍA DE DESARROLLO .......................................................................... 21
2.2.1. Metodología orientada a objetos. ......................................................................... 21
2.2.2. ¿Por qué esta metodología? ................................................................................ 23
2.4. ARQUITECTURA MULTINIVEL ................................................................................... 26
2.5. UML (UNIFIED MODELING LANGUAGE O LENGUAJE UNIFICADO DE
MODELACIÓN) ........................................................................................................................... 28
2.6. PHP ................................................................................................................................... 29
2.7. POSTGRESQL ............................................................................................................... 30
2.8. SISTEMAS DE BÚSQUEDA EN BASES DE DATOS. ............................................. 32
2.9. SISTEMAS DE GESTIÓN DE BASES DE DATOS. ................................................. 32
2.10. PLAN DE PRUEBAS .................................................................................................. 34
2.11. RED NACIONAL ACADÉMICA DE TECNOLOGÍA AVANZADA RENATA ...... 37
2.12. ANTECEDENTES DE LA INVESTIGACION ......................................................... 38
2.12.1 Open Network Laboratory ..................................................................................... 39
2.12.2 NetFPGA .................................................................................................................. 39
3. MARCO METODOLÓGICO .................................................................................................. 41
3.1. NIVEL DE INVESTIGACIÓN DEL DESARROLLO SOFTWARE ........................... 41
6
3.2. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE ANTECEDENTES DE
INFORMACIÓN .......................................................................................................................... 41
3.3. TÉCNICAS DE PROCESAMIENTO Y ANÁLISIS DE DATOS ................................ 42
3.4. METODOLOGÍA PARA EL DESARROLLO ............................................................... 42
3.5. METODOLOGÍA PARA LAS PRUEBAS DEL SOFTWARE .................................... 42
3.5.1. Diseño de casos de prueba .................................................................................. 43
4. DESARROLLO DEL PROYECTO ....................................................................................... 44
4.1. DESCRIPCIÓN DEL PROBLEMA ............................................................................... 44
4.2. FORMULACIÓN DEL PROBLEMA ............................................................................. 45
4.3. ANÁLISIS ......................................................................................................................... 47
4.3.1. Diagrama de casos de uso del módulo de administración de usuarios. ........ 49
4.3.2. Diagrama de caso de uso para el sistema de encolamiento ........................... 65
4.3.3. Diagrama de Flujo del Algoritmo de prioridad para el Sistema de
Encolamiento ........................................................................................................................... 67
4.3.4. Modelo vista-controlador (MVC) referente a los casos de uso planteados ... 71
4.3.5. Diagrama entidad relación del sistema. .............................................................. 77
4.3.6. Definición de la interfaz de usuario...................................................................... 80
4.3.7. Definición de plan de pruebas .............................................................................. 81
4.4 DISEÑO ........................................................................................................................... 82
4.4.1 Arquitectura del Sistema ....................................................................................... 82
4.4.2 Lenguaje de Modelación Visual UML .................................................................. 83
4.4.3 Sistema de Gestión de Bases de Datos ............................................................. 83
4.4.4 Identificación del Alcance Tecnológico ............................................................... 83
4.4.5 Identificación de los usuarios participantes y finales ........................................ 84
4.4.6 Modelo Físico de Datos ......................................................................................... 87
4.4.7 Metadatos ................................................................................................................ 88
4.4.8 Tuplas ....................................................................................................................... 95
4.4.9 Diseño del Plan de Pruebas. .............................................................................. 100
5. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS.............................................. 106
5.1. ARCHIVOS .................................................................................................................... 106
5.2. INTERFAZ DE LA APLICACIÓN ............................................................................... 111
7
CONCLUSIONES ......................................................................................................................... 120
RECOMENDACIONES ............................................................................................................... 121
REFERENCIAS BIBLIOGRÁFICAS Y REFERENCIAS WEB ............................................... 123
8
LISTA DE FIGURAS
Figura 1: Contraste de las actividades, métodos y notaciones de desarrollo de
software. ................................................................................................................ 22
Figura 2: Modelo de Ciclo de Vida Evolutivo. ........................................................ 24
Figura 3: Modelo de Ciclo de Vida Evolutivo 2 ...................................................... 25
Figura 4: Etapas del Desarrollo Evolutivo ............................................................. 26
Figura 5: Arquitectura Multinivel. ........................................................................... 28
Figura 6: Componentes más importantes de PostgreSQL .................................... 31
Figura 7: Diagrama de casos de uso del módulo de administración de usuarios. . 49
Figura 8: Consultar y Modificar Usuarios. ............................................................. 52
Figura 9: Consultar y Modificar Usuarios .............................................................. 52
Figura 10: CRUD Profesiones. .............................................................................. 53
Figura 11: CRUD Profesiones ............................................................................... 54
Figura 12: CRUD Organizaciones. ........................................................................ 55
Figura 13: CRUD organizaciones 2. ...................................................................... 55
Figura 14: Configuración del Sistema de Encolamiento ........................................ 56
Figura 15: Acceso a Registros. ............................................................................. 57
Figura 16: Consultar y Modificar Perfil .................................................................. 59
Figura 17: Consultar y Modificar Perfil 2 ............................................................... 59
Figura 18: Consultar y Modificar Perfil 3 ............................................................... 60
Figura 19: Consultar y Modificar Perfil 4 ............................................................... 60
Figura 20: Consultar y Modificar Perfil 5 ............................................................... 61
Figura 21: Iniciar Sesión. ....................................................................................... 62
Figura 22: Registrar Usuario. ................................................................................ 63
Figura 23: Diagrama de casos de uso para el sistema de encolamiento. ............. 65
Figura 24: Proceso Inicial y Proceso 2 .................................................................. 67
Figura 25: Proceso 1 ............................................................................................. 68
Figura 26: Proceso 3 ............................................................................................. 69
Figura 27: Proceso 4 ............................................................................................. 70
Figura 28: MVC Registro de usuario. .................................................................... 71
Figura 29: MVC Iniciar Sesión. .............................................................................. 72
Figura 30: MVC Configuración y modificación de perfil. ........................................ 73
Figura 31: MVC Configuración de experimento. .................................................... 74
Figura 32: MVC Entrega de información. .............................................................. 75
Figura 33: MVC Reporte de experimentos. ........................................................... 76
Figura 34: Diagrama entidad-relación del sistema. ............................................... 79
Figura 35: Definición de la interfaz de usuario. ..................................................... 81
9
Figura 36: Alcance Tecnológico. ........................................................................... 84
Figura 37: Modelo Físico de Datos. ....................................................................... 87
Figura 38: Tupla experimento ................................................................................ 95
Figura 39: Tupla usuarios ...................................................................................... 96
Figura 40: Página principal .................................................................................. 111
Figura 41: Panel administrador ........................................................................... 111
Figura 42: Información administrador .................................................................. 112
Figura 43: Usuarios por administrador ................................................................ 113
Figura 44: Gestionar organizaciones ................................................................... 113
Figura 45: Gestionar profesiones ........................................................................ 114
Figura 46: Registro de usuarios nuevos .............................................................. 115
Figura 47: Configuración sistema de encolamiento ............................................. 115
Figura 48: Manual de registro .............................................................................. 116
Figura 49: Panel principal usuario ....................................................................... 117
Figura 50: Perfil usuario ...................................................................................... 117
Figura 51: Nueva publicación .............................................................................. 118
10
LISTA DE TABLAS
Tabla 1: Actor usuario ........................................................................................... 50
Tabla 2: Actor Administrador del sistema .............................................................. 50
Tabla 3: Actor base de datos................................................................................. 50
Tabla 4: Catalogo de usuarios del módulo de administración de usuarios ............ 85
Tabla 5: Catálogo de usuarios sistema de encolamiento ...................................... 86
Tabla 6: Metadatos usuarios ................................................................................. 88
Tabla 7: Metadatos experimentos ......................................................................... 89
Tabla 8: Metadatos profesión ................................................................................ 90
Tabla 9: Metadatos organización .......................................................................... 91
Tabla 10: Metadatos log ........................................................................................ 92
Tabla 11: Metadatos contador experimento .......................................................... 93
Tabla 12: Metadatos log sistema de encolamiento ............................................... 94
Tabla 13: Tupla profesión ...................................................................................... 96
Tabla 14: Tuplas organización .............................................................................. 97
Tabla 15: Tuplas contador experimento ................................................................ 98
Tabla 16: Tuplas log .............................................................................................. 98
Tabla 17: Tuplas log sistema de encolamiento ..................................................... 99
Tabla 18: Caso de Prueba para registrar nuevo usuario ..................................... 100
Tabla 19: Caso de prueba ingreso al sistema web .............................................. 101
Tabla 20: Caso de prueba ingreso al sistema web .............................................. 102
Tabla 21: Caso de prueba configuración sistema de encolamiento .................... 103
Tabla 22: Caso de prueba manuales para el usuario. ......................................... 104
Tabla 23: Caso de prueba revisión final. ............................................................. 105
.
11
LISTA DE ANEXOS
ANEXO 1 - FORMATO DE REQUERIMIENTOS …………………………………..126
ANEXO 2 - LISTA DE CHEQUEO DE PRUEBAS REALIZADAS ……................138
12
RESUMEN
El proyecto U2ROUTE promueve investigaciones en cuanto a protocolos de
comunicación y calidad de servicio, mediante una infraestructura capaz de simular
eventos que pueden ocurrir en la transmisión de datos. Dentro de su plataforma
web implementa un módulo capaz de gestionar la información de los usuarios que
interactúan en ella, llamado Módulo de Administración de Usuarios y un Algoritmo
de Encolamiento, encargado de brindar prioridad a la ejecución de las pruebas
que se configuran continuamente dado un parámetro establecido por el
Administrador. Este documento describe como se desarrollaron ambos módulos a
partir de investigaciones sobre aplicaciones similares, hasta la ingeniería del
software que permitió el desarrollo de los prototipos funcionales implementados en
U2ROUTE.
PALABRAS CLAVE: U2-ROUTE, usuarios, software, gestión de usuarios,
encolamiento, pruebas, aplicativo web.
ABSTRACT
The U2ROUTE project promotes research in terms of communication protocols
and quality service, through an infrastructure capable of simulate events that can
happened during the data transmition. Within its web platform, implements a
module able to manage information from users who interact with it, called User
Management Module and a Queuing Algorithm responsible for providing priority to
the implementation of the tests that are configured constantly, with a parameter
established by the Administrator.
This document describes how both modules were developed from research on
similar applications, to software engineering that allowed the development of
functional prototypes implemented in U2ROUTE.
KEY WORDS: U2ROUTE, users, software, user management, queuing, test, web
application.
13
GLOSARIO
Administrador Es la persona encargada de llevar a cabo la planeación de las actividades en un proyecto de ingeniería de software y velar por que se cumplan, asigna tareas a todos los miembros del equipo de desarrollo y se encarga de motivarlos a llevar a cabo las actividades. Actividad Un patrón de trabajo realizado juntos por un solo propósito. Una actividad puede utilizar o producir productos de trabajo y pueden ser rastreados por un elemento de trabajo. Análisis de código Comprobación de código de la conformidad con directrices de diseño. Código análisis va más allá de la compilación en busca de codificación común y errores de diseño determinado por una serie de directrices. Beta-versión Una versión preliminar de un producto que se envía a los clientes y socios para la evaluación y la retroalimentación. Build Un llamado conjunto de productos (componentes de software) producido, en general, por la compilación, desde un discreto conjunto de versiones fuente. Ciclo de vida Las fases de una solución pasa por desde el momento en que es concebido hasta el momento en que se retiró de servicio. Constraint o limitación Una condición lógica en un modelo de la sección. Cada obstáculo es encarnado por un método de validación que se ejecuta en un dominio de clase en su modelo.
14
Evaluación o revisión de código Evaluación de código para mejorar su calidad y las capacidades del equipo de desarrollo. Tipos de revisión de código incluyen revisión formal, basada en peer-examen, y un tercero de examen. Fase Una clara división dentro de un modelo de proceso o ciclo de vida del producto, por lo general, una transición fundamental en el desarrollo de un producto o servicio, que culminaron en un gran hito o externa, o que representa una transición fundamental en el desarrollo de un producto o servicio. Iteración Un período fijo de tiempo del calendario, generalmente entre 1 y 6 semanas, para programar tareas y la planificación de actividades. Normalmente, las repeticiones son numeradas consecutivamente y se suceden secuencialmente. Milestone o hito Un punto sobre el calendario del proyecto en el que el equipo del proyecto evalúa los progresos y la calidad, evaluación y desviaciones en su alcance y especificaciones. Un proyecto puede tener muchos hitos provisional sólo para uso interno, señal de que una transición dentro de una etapa y ayudar a dividir los grandes proyectos viables en pedazos. Hitos externo o hitos principales suelen ocurrir al final de las principales fases de trabajo y están asociados con la realización de grandes prestaciones. Modelo de ciclo de vida Una partición de la vida de un producto en fases que guían el proyecto desde la identificación de las necesidades de los clientes a través de los productos de jubilación. Prototipo Un primer tipo, la forma o el ejemplo de un producto o componente del producto que sirve como un modelo para fases posteriores o para la final, versión completa del producto. Este modelo (físico, electrónico, digital, analítico, etc.) pueden ser utilizados para los siguientes, además de otros, objetivos: evaluar la viabilidad de una nueva tecnología o desconocidos; la evaluación técnica o la mitigación de riesgo; la validación de los requisitos; demostrando crítica características; calificación de un producto, un proceso de calificación; caracterizar el desempeño o las características del producto; elucidar principios físicos.
15
Requerimiento Una condición o capacidad que necesita un usuario para resolver un problema o alcanzar un objetivo. Riesgo Un tipo de elemento de trabajo, la grabación de un posible evento con un resultado indeseable. Los riesgos deben ser identificados, asignados, y si el impacto es, probablemente, y realmente indeseable, mitigado. Subsistema Una pequeña porción de un sistema. Versión El estado de un tema de control de código fuente en la que refleja uno o más cambios de una forma anterior. Cuanto mayor sea el número de versión, más reciente la versión. Usuario final La persona que utiliza una solución y obtiene resultados de ésta, en contraposición al cliente, que paga por ello e ingresa la información a la aplicación. JAR Un archivo JAR son paquetes de archivos de clases, imágenes, sonidos y / u otros datos digitales en un solo archivo. CRUD (Create Read Update Delete) Son las funciones elementales de una base de datos o la capa de persistencia en una aplicación de software. Especificación CU Define el flujo básico y alterno (excepciones) que se pueden presentar en los distintos escenarios durante la ejecución de un caso de uso y define su funcionalidad. CGI Interfaz de entrada común (en inglés Common Gateway Interface, abreviado CGI) es una importante tecnología de la World Wide Web que permite a un cliente
16
(navegador web) solicitar datos de un programa ejecutado en un servidor web. CGI especifica un estándar para transferir datos entre el cliente y el programa. Es un mecanismo de comunicación entre el servidor web y una aplicación externa cuyo resultado final de la ejecución son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el nombre de CGIs.
ISAPI Es una interfaz, de programación de aplicaciones (API) para el servidor web de Microsoft, IIS (Internet Information Server). La ISAPI permite que los programadores puedan desarrollar aplicaciones basadas en web que se procesen mucho más rápidamente que los programas CGI. Esto es así porque están más integrados con el servidor web. Además del IIS, hay otros servidores web que soportan ISAPI. Licencia Pública General de GNU Más conocida por su nombre en inglés GNU General Public License o simplemente sus siglas del inglés GNU GPL, es una licencia creada por la Free Software Foundation en 1989 (la primera versión), y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios.
17
INTRODUCCIÓN
Actualmente con el crecimiento vertiginoso de los sistemas de información y las
tecnologías de la información encontramos que cada vez son más adaptables,
flexibles y cómodos aquellos software que se encuentran compuestos por módulos
independientes, que realizando funciones determinadas y unidos por una
estructura organizativa, se obtiene un sistema que funciona de forma ordenada,
segura y consistente para los usuarios finales que utilicen dichos sistemas.
Se deben tener en cuenta aspectos muy importantes para la elaboración de un
Sistema de Información tales como qué es lo que se debe hacer, cómo se va a
hacer y con qué herramientas se va a realizar dicho proceso, es decir si se tiene
todo esto claro al inicio del proyecto muy seguramente los inconvenientes que se
presenten no generarán demasiados y graves conflictos que intervengan con el
buen fin del proyecto.
El proyecto de investigación "U2-ROUTE (UNIVERSITARY UNIVERSAL
ROUTER) UNA HERRAMIENTA DE INVESTIGACIÓN EN PROTOCOLOS Y
CALIDAD DE SERVICIO SOBRE INTERNET" es una plataforma mediante la cual
se podrán configurar experimentos de tratamiento de paquetes en un router
remoto, que puede ser configurado para generar simulaciones para probar
protocolos y calidad de servicio en la transmisión de datos. El proyecto se basa en
la interacción remota con un dispositivo electrónico lo cual hace que sea viable o
de mejor práctica, la implementación de una interfaz web que permita a los
usuarios configurar las pruebas y observar resultados de las mismas que son
efectuadas sobre el enrutador.
Con el fin de desarrollar este proyecto se crea una alianza entre el grupo de
investigación GITEL de la Universidad Pontificia Bolivariana Seccional
Bucaramanga y TICs de la Universidad Católica de Pereira. Para lograr la
realización del proyecto, se debe determinar una configuración para que el Router
opere dentro de la red RENATA y que a su vez permita ser administrado de forma
remota, con la ayuda de una plataforma adecuada para este tipo de tecnología,
con el fin que diferentes usuarios de grupos de investigación puedan acceder a
esta herramienta para realizar sus investigaciones y desarrollos en torno al tema.
18
U2ROUTE se basa en la interacción remota entre los clientes y la plataforma web,
permitiendo que se envíe información hacia el enrutador con los parámetros
necesario para generar pruebas sobre este mismo. A su vez el enrutador se
comunica con los usuarios entregando los resultados de las simulaciones que se
le han encomendado, esta información es entregada en un archivo plano el cual
debe ser procesado y administrado para permitir que toda la información allí
descrita pueda ser evaluada y confrontada o hacer con esta cualquier tipo de
análisis pertinente o necesario.
Buscando generar la mejor solución al problema planteado, teniendo en cuenta los
aspectos anteriormente mencionados se desarrollará un Módulo de Administración
de Usuarios y un Algoritmo de Encolamiento los cuales trabajarán en conjunto con
el Proyecto en Línea de Investigación U2ROUTE, el primero encargándose de una
gestión ágil al administrador de la plataforma de la información de los usuarios y el
segundo permitiendo el orden de ejecución de pruebas configuradas por los
usuarios. El desarrollo de la aplicación se basará en el modelo de desarrollo
evolutivo en cuanto al Modelo de Ciclo de Vida del Software se refiere; ya que se
presentan versiones a las organizaciones participes del proyecto, logrando que se
involucre y logre visualizar el progreso del mismo. Esto ayuda de manera
recíproca a satisfacer constantemente las necesidades y/o requerimientos que
surgen en cada prueba que se aplica al sistema.
La necesidad surge de tratar de generar innovación, mejorar y ampliar el conocimiento frente a las nuevas generaciones que se están educando en las universidades y poder brindar educación de alto nivel para que sean competitivos en el campo laboral y personal. Este documento describe investigaciones, documentación técnica y marco conceptual para el diseño de los módulos anteriormente mencionados.
19
1. OBJETIVOS
1.1. OBJETIVO GENERAL Diseñar e implementar un módulo software que permita llevar a cabo la gestión de usuarios y diseñar un algoritmo de encolamiento en el proyecto U2-ROUTE 1.2. OBJETIVOS ESPECÍFICOS
Identificar y clasificar la información requerida para el manejo de los procesos en un sistema web de administración de usuarios y un algoritmo de encolamiento.
Analizar la información recolectada para la realización de la aplicación web y algoritmo de prioridad.
Realizar el diseño de una aplicación web, que pueda ser evaluada como interfaz amigable al usuario, cuente con reglas de administración, tanto del sitio como de los usuarios para un mejor manejo del sistema web.
Implementar la aplicación web del Módulo de Administración de Usuarios.
Diseñar una solución al algoritmo de prioridad teniendo en cuenta los requerimientos de pruebas locales, pruebas foráneas y su orden de llegada.
Desarrollar las pruebas pertinentes a la aplicación web y al algoritmo de encolamiento.
20
2. MARCO TEÓRICO Para un mejor acercamiento sobre el módulo de administración de usuarios Y
ALGORITMO DE ENCOLAMIENTO para un laboratorio remoto es necesario tener
en cuenta los siguientes conceptos claves que fueron vitales para el análisis,
diseño y construcción de este SISTEMA web. Estos conceptos se definen de
manera detallada logrando así un mayor entendimiento de lo que se desea lograr
con este APLICATIVO, se analizan temas sobre la base de datos el tipo de motor
de base de datos a utilizar, el lenguaje de programación y los tipos de algoritmos
que se tendrán en cuenta para el buen fin de este proyecto. Lo dicho
anteriormente contiene también sus desventajas, sus inconvenientes pero también
sus ventajas para este proceso de investigación Y DESARROLLO.
2.1. PAPEL DE LA INGENIERÍA DE SOFTWARE
Las personas con conocimientos especializados en aplicaciones de software se
llaman ingenieros de software. Ellos implementan y diseñan aplicaciones de
software a través de la utilización de diferentes metodologías de desarrollo, es
decir, mediante el uso de un marco de trabajo usado para estructurar, planificar y
controlar el proceso de desarrollo en sistemas de información.
Estas aplicaciones de software serán utilizadas para una variedad de propósitos
de las prácticas comerciales a fines de suplir una necesidad. Hay muchas
aplicaciones de software disponibles en el mercado como las aplicaciones de
lenguaje, aplicaciones de oficina, los paquetes de entretenimiento, aplicaciones
para la educación como también para gestionar proyectos.
Con el paso del tiempo, la demanda de software ha crecido en cantidades
vertiginosas provocando que el futuro de la industria del software crezca cada año
más y más. Cada vez más empresas están creando su propio software, es decir,
aplicativos desarrollados por ellos los cuales se realizaron con base en
requerimientos específicos de acuerdo a cierto número de necesidades por suplir.
Esto se hace con el fin de mejorar la calidad de los aplicativos, aumentar la
productividad de los ingenieros de software, facilitar el control del proceso de
construcción de estos, suministrando a los desarrolladores las bases necesarias
para crear programas de alta calidad en una forma eficiente y ordenada con el fin
de que se garantice la producción y el mantenimiento de los productos software
desarrollados en el plazo establecido y dentro del costo estimado.
21
2.2. METODOLOGÍA DE DESARROLLO
Los sistemas de información que se desarrollan comúnmente, sirven para
diversas finalidades que van desde el procesamiento de las transacciones de una
empresa hasta proveerla de la información necesaria para decidir sobre asuntos
que se presentan con frecuencia.
En algunos casos los factores que deben considerarse en un proyecto de sistema
de información, tales como el tipo de servidor más adecuado donde debe
instalarse o la tecnología de comunicaciones que se va a utilizar, el impacto del
nuevo sistema sobre los empleados de la empresa y las características
específicas que el sistema debe tener se pueden determinar de manera
secuencial. Todas estas situaciones están determinadas por tres metodologías
básicas: estructural, orientada a objetos y tradicional, de los cuales se mencionará
una en particular: Metodología orientada a objetos.
2.2.1. Metodología orientada a objetos.
La metodología orientada a objetos1 para el desarrollo de sistema es el conjunto
de actividades que los analistas, diseñadores y usuarios realizan para desarrollar
e implantar un sistema de información.
Se caracteriza por:
Eliminar fronteras entre fases debido a la naturaleza iterativa del desarrollo
orientado a objetos.
Una nueva forma de concebir los lenguajes de programación y su uso al
incorporarse bibliotecas de clases y otros componentes reutilizables.
Un alto grado de iteración y solapamiento, lo que lleva a una forma de
trabajo muy dinámica.
Fomentar la reutilización de componentes, entre otros.
A diferencia de las metodologías estructuradas, se identifican inicialmente los objetos del sistema para luego especificar su comportamiento. Existen un gran número de metodologías orientadas a objetos, pero para el proyecto se basará
1 Weitzenfeld, Alfredo. (2005). Ingenieria del Software Orientada a Objetos con UML, Java e
internet. Pag 44.
22
específicamente en la que plantea el autor Alfredo Weitzenfeld, en su libro Ingeniería del Software Orientada a Objetos con UML, Java e Internet.
Durante las actividades de desarrollo se utilizan diferentes herramientas de modelado:
Diagrama de casos de uso: Especifican un sistema en término de su funcionalidad.
Diagrama de transición de estado: Describen los cambios de estado en los objetos.
Diagramas de secuencia: Sirven para describir los aspectos dinámicos del sistema.
Diagramas de Colaboración: Se utilizan para describir la comunicación entre objetos de un sistema.
Esta metodología permite trabajar el desarrollo de las diferentes etapas de la ingeniería del software con diferentes métodos, y su notación respectiva como se aprecia en la siguiente Ilustración:
Figura 1: Contraste de las actividades, métodos y notaciones de desarrollo de software.
Fuente: Ingeniería De Software Orientada A Objetos Con UML, Java e Internet – Alfredo Weitzenfeld
23
El autor en su libro explica cómo debe definirse una correcta estrategia para lograr
el objetivo del sistema de información a desarrollar, el prototipo a desarrollar (bien
sea, de requisitos, análisis, diseño, verticales y/o de factibilidad) dependiendo de
la etapa de la ingeniería del software en la que se encuentre, la importancia de la
reutilización de código, el tipo de herramientas que pueden utilizarse para realizar
de manera más amena todo este proceso, y los diferentes modelos de ciclo de
vida a seguir, dadas las exigencias y adecuaciones que tenga el proyecto para de
esta manera, lograr desarrollar un sistema de información de calidad.
2.2.2. ¿Por qué esta metodología?
Es necesario un proceso que acepte muchas iteraciones ya que el cliente requiere
una constante comunicación para cambios o nuevos requerimientos y realizar
entregas frecuentes del proceso que se lleva a cabo; La metodología orientada a
objetos es una metodología de iteración que permite construir a este ritmo y a su
vez integrar el representante del cliente en el proceso para que trabaje junto al
equipo de desarrollo.
El problema con la implementación de cambios imprevistos es que tienden a
degradar la estructura del software, por lo que los cambios se hacen cada vez más
difíciles de implementar. La programación extrema aborda este problema
sugiriendo que se debe refactorizar constantemente el software. Esto significa que
el equipo de programación busca posibles mejoras del software y las implementa
inmediatamente. Por lo tanto, el software siempre debe ser fácil de entender y
cambiar cuando se implementen nuevas versiones.
2.3. MODELO DE CICLO DE VIDA Y ENFOQUE DE DESARROLLO
Para cada etapa vista en la metodología de desarrollo de software existen sub-
etapas o tareas. El modelo de ciclo de vida y el enfoque de desarrollo permiten
definir un orden, coordinación, enlace y retroalimentación entre dichas etapas,
mediante la descripción de las fases principales de desarrollo de software y la
definición las fases primarias esperadas de ser ejecutadas durante esas fases,
permitiendo así administrar el progreso del desarrollo del aplicativo y el espacio de
trabajo para la definición de un detallado proceso de desarrollo de software.
24
Para solucionar el problema planteado, se considera apropiado utilizar el modelo
evolutivo2 , ya que constantemente a lo largo del proyecto se estará atado a
posibles cambios de requerimientos. La práctica ha demostrado que obtener todos
los requerimientos al comienzo del proyecto es extremadamente difícil, no solo por
la dificultad del cliente de transmitir su idea, sino porque estos requerimientos
evolucionan durante el desarrollo y de esta manera, se pueden eliminar algunos y
surgir otros.
En el modelo de ciclo de vida evolutivo, este problema se afronta mediante la
iteración de ciclos requerimientos-desarrollo-evaluación, es decir, al realizar una
versión del aplicativo dado unos requerimientos, se evalúa si realmente se
cumplen las expectativas y si el software está solucionando el problema planteado
inicialmente.
Figura 2: Modelo de Ciclo de Vida Evolutivo.
Fuente: Implementación y Debugging, Cap. 1.
Resulta ser un modelo muy útil cuando se desconocen la mayoría de los requerimientos iniciales, o no están completos. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
2 Implementación y Debugging, Capitulo 1: Metodologías y Ciclos de Vida. Pág. 29
25
Todo lo que se debe hacer es construir un subconjunto de requerimientos conocidos y a su vez comprender dichos requerimientos. Es normal que al inicio del proyecto surjan requerimientos nuevos cuando el sistema sea desplegado en su totalidad.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, entre otros, desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
Figura 3: Modelo de Ciclo de Vida Evolutivo 2
Fuente: WikiLearning/Ingeniería del Software
A diferencia del Modelo de Ciclo de Vida de Prototipos, busca reemplazar el viejo sistema con uno que tenga la propiedad de satisfacer los nuevos requerimientos lo más rápido posible.
26
Figura 4: Etapas del Desarrollo Evolutivo
Fuente: WikiLearning/Ingeniería del Software
2.4. ARQUITECTURA MULTINIVEL
En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base en las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software por su semejanza con los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software; viendo así la especificación y la estructura global del sistema como un nuevo tipo de problema buscando así su organización más óptima.
27
En la actualidad los aplicativos web hacen una parte muy importante del mercado del software y más aún cuando se trata de un sitio con una buena arquitectura con soporte a errores y que permita una funcionalidad permanente para los usuarios, tal como los sistemas desarrollados para bancos y demás entidades similares, donde se presenta la necesidad de tener un portal web funcionando todo el tiempo, que no presente “caídas” o fallas en su funcionamiento, que asegure la integridad de la información que maneja y sea fácil de usar. (Sommerville, 2005) Al hablar del desarrollo de aplicaciones Web resulta adecuado presentarlas dentro de las aplicaciones multinivel. Los sistemas típicos cliente/servidor pertenecen a la categoría de las aplicaciones de dos niveles. La aplicación reside en el cliente mientras que la base de datos se encuentra en el servidor. En este tipo de aplicaciones el peso del cálculo recae en el cliente, mientras que el servidor hace la parte menos pesada, y eso que los clientes suelen ser máquinas menos potentes que los servidores. Además, está el problema de la actualización y el mantenimiento de las aplicaciones, ya que las modificaciones a la misma han de ser trasladadas a todos los clientes. Para solucionar estos problemas se ha desarrollado el concepto de arquitecturas de tres niveles: interfaz de presentación, lógica de la aplicación y los datos. La capa intermedia es el código que el usuario invoca para recuperar los datos deseados. La capa de presentación recibe los datos y los formatea para mostrarlos adecuadamente. Esta división entre la capa de presentación y la de la lógica permite una gran flexibilidad a la hora de construir aplicaciones, ya que se pueden tener múltiples interfaces sin cambiar la lógica de la aplicación. La tercera capa consiste en los datos que gestiona la aplicación. Estos datos pueden ser cualquier fuente de información como una base de datos o documentos XML. Hoy día, la Arquitectura Multinivel es muy usada, segura, estable y escalable así como de fácil administración. Convertir un sistema de tres niveles a otro multinivel es fácil ya que consiste en extender la capa intermedia permitiendo que convivan múltiples aplicaciones en lugar de una sola (Ver figura 5).
28
Figura 5: Arquitectura Multinivel.
Fuente: J2EE desarrollo de aplicaciones web, Cap. 2.
2.5. UML (UNIFIED MODELING LANGUAGE O LENGUAJE UNIFICADO DE MODELACIÓN)
Fue creado con la intención de obtener un único sistema para modelar y documentar sistemas de información y procesos de gestión, utilizando técnicas de análisis y diseño orientado a objetos. UML permite expresar mediante símbolos gráficos la semántica deseada y especificar modelos completos con una mínima ambigüedad. Se puede establecer una correspondencia desde este modelo a un modelo orientado a objetos (objeto-relacionales u objetos puros). UML define las siguientes técnicas:
Los diagramas de clases representan la vista de diseño estática y de procesos en términos de clases, relaciones, interfaces y colaboraciones.
Los diagramas de objetos representan los objetos y sus relaciones. Representan la vista de diseño estática y de procesos desde una perspectiva prototípica. Se corresponden con los diagramas de colaboración simplificados sin representar los envíos de mensajes.
Los diagramas de actividades representan el comportamiento de una operación en términos de acciones
Los diagramas de casos de uso representan las funciones del sistema desde el punto de vista del usuario mediante un conjunto de casos de uso, actores y relaciones.
29
Los diagramas de estados-transiciones representan el comportamiento de una clase en términos de estados, muestran el estado de un objeto y las causas por las que puede cambiar de un estado a otro.
Los diagramas de secuencia son una representación temporal de los objetos y sus interacciones.
2.6. PHP PHP3, acrónimo de "PHP: Hypertext Preprocessor", es un lenguaje "Open Source" interpretado de alto nivel, especialmente pensado para desarrollos web y el cual puede ser incrustado en páginas HTML. La mayoría de su sintaxis es similar a C, Java y Perl y es fácil de aprender. La meta de este lenguaje es permitir escribir a los creadores de páginas web, páginas dinámicas de una manera rápida y fácil, aunque se pueda hacer mucho más con PHP. También les permite involucrarse con aplicaciones de contenido dinámico sin tener que aprender todo un nuevo grupo de funciones.
Lo que distingue a PHP de lenguajes que se ejecutan del lado del cliente como JavaScript, es que el código es ejecutado en el servidor, generando HTML y enviándolo al cliente. El cliente recibirá los resultados de ejecutar el script, sin ninguna posibilidad de determinar qué código ha producido el resultado recibido. El servidor web puede ser incluso configurado para que procese todos los archivos HTML con PHP y entonces no hay manera que los usuarios puedan saber que tienes debajo de la manga.
Lo mejor de usar PHP es que es extremadamente simple para el principiante, pero a su vez, ofrece muchas características avanzadas para los programadores profesionales.
Aunque el desarrollo de PHP está centrado en programación de scripts en lado-servidor, se puede utilizar para muchas otras cosas. Cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el contenido de manera dinámica (por ejemplo obteniendo información de una base de datos). El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía al cliente. Mediante extensiones es también posible la generación de archivos PDF, Flash, así como imágenes en diferentes formatos. Permite la conexión a diferentes tipos de servidores de bases de datos tales como MySQL, PostgreSQL, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite. 3 http://co.php.net/get/php_manual_es.html.gz
30
PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos, tales como Unix (y de ese tipo, como Linux o Mac OS X) y Microsoft Windows, y puede interactuar con los servidores de web más populares ya que existe en versión CGI, módulo para Apache, e ISAPI. PHP es una alternativa a las tecnologías de Microsoft ASP y ASP.NET (que utiliza C# y Visual Basic .NET como lenguajes), a ColdFusion de la empresa Adobe, a JSP/Java y a CGI/Perl. Aunque su creación y desarrollo se da en el ámbito de los sistemas libres, bajo la Licencia Pública General GNU, existe además un entorno de desarrollo integrado comercial llamado Zend Studio.
2.7. POSTGRESQL
PostgreSQL 4 es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales. PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el sistema continuará funcionando. A continuación se ilustra de manera general los componentes más importantes en un sistema PostgreSQL. Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL como
administrador de bases de datos. La conexión puede ocurrir via TCP/IP ó sockets locales.
Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado de escuchar por un puerto/socket por conexiones entrantes de clientes. También es el encargado de crear los procesos hijos que se encargaran de autentificar estas peticiones, gestionar las consultas y mandar los resultados a las aplicaciones clientes
Ficheros de configuración: Los 3 ficheros principales de configuración utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf
4 http://www.postgresql.org.es/sobre_postgresql
31
Procesos hijos PostgreSQL: Procesos hijos que se encargan de autentificar a los clientes, de gestionar las consultas y mandar los resultados a las aplicaciones clientes.
PostgreSQL share buffer cache: Memoria compartida usada por PostgreSQL
para almacenar datos en caché. Write-Ahead Log (WAL): Componente del sistema encargado de asegurar la
integridad de los datos (recuperación de tipo REDO). Kernel disk buffer cache: Caché de disco del sistema operativo
Disco: Disco físico donde se almacenan los datos y toda la información
necesaria para que PostgreSQL funcione.
Figura 6: Componentes más importantes de PostgreSQL
Fuente: http://www.postgresql.org.es/sobre_postgresql
32
2.8. SISTEMAS DE BÚSQUEDA EN BASES DE DATOS. Un sistema o motor de búsqueda es el mecanismo por el cual la información almacenada puede ser recuperada por el usuario, mediante una interfaz provista para comunicarlo con la base de datos y realizar operaciones para extraer la información que se solicita. En una biblioteca digital no es cuestionable la utilización de un motor de búsqueda. El principal servicio es la consulta de información y como no se puede tener toda la colección en línea al mismo tiempo, por muy pequeña que sea, siempre será necesario hacer una revisión y extracción sólo de los materiales que cumplen con los intereses del usuario. En muchos casos se requiere más de un motor de búsqueda para una colección de cinco documentos grandes, que en una colección de 20 documentos pequeños bien definidos. Los científicos de la información y los bibliotecarios han estudiado por décadas los hábitos de búsqueda de los usuarios. Recientemente, estos estudios se refieren a los sistemas de información tradicionales, tales como encontrar un patrón para encontrar las necesidades de información, o cómo hacer sistemas sencillos para la búsqueda de información en servicios en línea de catálogos bibliotecarios u otras bases de datos. Los usuarios de sistemas de información de no pertenecen a una misma audiencia que requiere el mismo tipo de información, representada y entregada de la misma manera. Algunos sólo requieren información mínima, mientras que otros requieren materiales detallados de todo lo que se tenga sobre un tema. Algunos quieren sólo información de alta calidad, mientras que a otros no les interesa ni siquiera la fuente. Algunos requieren la información de inmediato, y otros no tienen problema en esperar a que la información llegue tiempo después.
2.9. SISTEMAS DE GESTIÓN DE BASES DE DATOS. 5 Debido a la complejidad de una base de datos (creación de estructuras, modificación de datos, eliminación de datos, actualización de datos, modificación de estructuras, etc.), existen los sistemas de gestión de bases de datos (SGBD o DBMS6). Según Whitten(1992), un sistema de gestión de bases de datos es un software informático especializado y disponible en el mercado que se utiliza para creación, acceso, control y gestión de la base de datos.
5 Desarrollo de sistemas de información: Una metodología basada en el modelado – Vicenҫ Fernández Alarcón. 6 En ingles: Data Base Management System (DBMS)
33
Los componentes principales de un sistema de gestión de base de datos son el lenguaje de definición de datos (DDL7) y el lenguaje de manipulación de datos (DML 8 ) según el autor del libro “Desarrollo de sistemas de información: una metodología basada en el modelado”. El lenguaje de definición de datos (DDL) tiene como objetivo poder crear, modificar y eliminar tablas (entidades en un modelo lógico), campos (los atributos en un modelo lógico) y las relaciones que puedan existir entre las tablas de la base de datos. Además, a través del lenguaje de definición de datos (DDL), los analistas de sistemas y analistas de bases de datos pueden establecer los permisos de utilización de cada tipo de usuarios. A esta parte, se le llama lenguaje de definición de vistas (VDL9) Existen distintos objetivos que deben cumplir los SGBD:
Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.
Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.
Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida, se actualice de forma coherente, es decir, que todos los datos similares se actualicen de manera simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones.
Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.
Manejo de transacciones. Una transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la
7 En ingles: Data Definition Language (DDL) 8 En ingles: Data Manipulation Language (DML) 9 En ingles: Visual Definition Language (VDL)
34
que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.
Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados.
Algunos ejemplos de sistemas de gestión de bases de datos son Oracle,
SqlServer, MySQL Server, entre otros.
2.10. PLAN DE PRUEBAS
Las siguientes definiciones pueden ser utilizadas para precisar ciertos conceptos
conocidos de manera informal como “bugs”
Una falla (failure) ocurre cuando un programa no se comporta de manera
adecuada. La Falla es una propiedad (estadística) de un sistema en
ejecución.
Una falta (fault) tiene lugar en el código del programa. La existencia de una
falta en el programa puede ocasionar una falla en el sistema. No puede
haber una falta si el programa no falla.
Un error es una acción humana que provoca que un software contenga una
falta. Un error puede significar la existencia de una falta en el programa, lo
cual hace que el sistema falle.
Un aspecto importante relacionado con los conceptos anteriores es que no se
puede garantizar ni probar que un sistema jamás falle, sino que solo se puede
demostrar que contiene fallas. En otras palabras, no encontrar faltas no significa
que la prueba haya sido exitosa. Solo lo es si ha encontrado faltas. Sin embargo,
pruebas exitosas significan que no se ha desarrollado un buen sistema.
Dada la dificultad de probarlo y de encontrar faltas, el encargado de detectarlas en
el código es generalmente una persona distinta al desarrollador del sistema. Esto
también significa un costo adicional en el desarrollo de éste, por lo cual a veces
sólo se prueban las partes principales del sistema.
35
2.10.1. Tipos de pruebas
Los tipos de prueba se dividen de manera general en pruebas de VERIFICACIÓN
y VALIDACIÓN. En el primer caso se revisa si el resultado corresponde a la
especificación del sistema, es decir, si se está construyendo el sistema de manera
correcta, algo que por sí solo no garantiza la satisfacción de los clientes. En el
segundo caso, se revisa si el resultado es realmente lo que el cliente quería, en
otras palabras, si se está construyendo el sistema correcto, de manera que tanto
la especificación como el resultado lo sean. El sistema debe validarse
continuamente durante su proceso de desarrollo de manera que siempre
corresponda con lo especificado. La validación se basa en el modelo de casos de
uso.
Las técnicas utilizadas para realizar las pruebas son muy variadas, pero se
pueden destacar las siguientes:
PRUEBA BASADA EN REQUISITOS O PRUEBAS DE CASO DE USO:
Intenta llevar a cabo pruebas basadas directamente en la especificación de
requisitos. Pueden utilizarse los mismos casos de uso originales como
casos de prueba. También pueden ser utilizados para verificar las
especificaciones de rendimiento o de escala completa. Se trata de verificar
que el sistema final cumple con las especificaciones funcionales por los
casos de uso originales.
PRUEBAS ERGONÓMICAS: Tienen como propósito probar los aspectos
ergonómicos del sistema, en otras palabras, las interfaces hombre-máquina
en el caso de que éstas existan. Por ejemplo, se prueba si las interfaces
son congruentes con los casos de uso a los cuales corresponden, o entre
diferentes casos de uso, si los menús son lógicos y legibles, si los mensajes
del sistema son visibles, si se puede entender los mensajes de falla,
etcétera.
PRUEBAS DE DOCUMENTACIÓN DE USUARIO: Tiene como finalidad
probar la documentación de usuario, incluyendo el manual de éste y la
documentación de mantenimiento y servicio. Se prueba que los manuales y
el comportamiento del sistema sean congruentes entre sí, que sean
legibles, con buena redacción y en general que sean comprensibles.
PRUEBAS DE ACEPTACIÓN O VALIDACIÓN: Pretende lograr una
revisión final por parte de la organización que solicitó el sistema, lo cual, a
menudo, significa validación del sistema. El sistema se prueba en su
ambiente real por un periodo extenso. Cuando se termina la prueba, se
36
toma la decisión de aceptar o no el producto. Este tipo de prueba es a
veces conocida como prueba alfa. Si no existe un cliente particular que
haya solicitado el sistema, por ejemplo en el caso de un producto de
software de venta al público, a menudo se hace una PRUEBA BETA, lo
cual implica que antes de enviarlo al público en general, el producto es
probado por clientes seleccionados que utilizan el sistema y reportan las
fallas experimentadas.
2.10.2. Nivel de pruebas
Existen tres niveles principales para aplicar las diversas técnicas de pruebas:
PRUEBAS DE UNIDAD: Mediante esta prueba sólo una unidad es probada
como tal, como una clase, un paquete de servicio o un subsistema. La
prueba de es la de más bajo nivel. En un sistema tradicional son, a
menudo, pruebas de procedimientos o subrutinas. Tradicionalmente una
prueba de unidad consiste en una prueba estructural (o de caja blanca), lo
cual requiere conocer el diseño interno de la unidad, y una prueba de
especificación (de caja negra), basada sólo en la especificación del
comportamiento externamente visible de la unidad. Normalmente ambas
pruebas son necesarias y se complementan entre sí. Algunas pruebas
comprendidas son: prueba de especificación o caja negra, pruebas basada
en estado y prueba estructural.
PRUEBA DE INTEGRACIÓN: En ella se verifica que las unidades trabajen juntas correctamente. Ambas pueden ser realizadas mediante casos de uso de pruebas, los cuales pueden ser aplicados a clases, paquetes de servicio, subsistemas y el sistema completo. La prueba de integración se basa principalmente en la prueba de casos de uso, que se lleva a cabo a partir de los diagramas de secuencia, mediante la cual se pueden identificar los estímulos enviados entre el usuario y el sistema.
PRUEBAS DE SISTEMA: Verifica el sistema completo o su aplicación como tal. Se toma el punto de vista del usuario final y los casos de uso de pruebas ejecutan acciones típicas del usuario.
37
2.10.3. Proceso de pruebas
El proceso de pruebas involucra consideraciones similares al del proceso de
desarrollo de software, incluyendo estrategias, actividades y métodos, los cuales
deben ser aplicados de manera concurrente con el proceso de desarrollo de
software. En particular, las actividades de pruebas abarcan los siguientes
aspectos: planeación, construcción y ejecución. Por lo general, se mantiene una
bitácora de prueba durante todo el proceso de pruebas.
Existen diversas estrategias para el proceso de pruebas, entre las que se
destacan en el orden en que se van a llevar a cabo, la partición de equivalencias
de pruebas que se van a aplicar y la posibilidad de automatizarlas.
ALCANCE DE LAS PRUEBAS: Tiene como propósito identificar el tipo,
número y casos de prueba que se aplicarán para revisar los diferentes
aspectos del sistema. Si se considera que los tipos de pruebas son
bastante amplios y extensos, el objetivo es seleccionar un número pequeño
pero razonable de casos de prueba dentro de un gran número de posibles
pruebas donde la probabilidad de encontrar faltas sea alta. Se define la
partición de equivalencias según conjuntos equivalentes de pruebas
definiendo un grupo de condiciones donde el sistema o algún componente
se comportarán de manera similar ante diferentes pruebas. La idea es
escribir casos de prueba para cada conjunto de equivalencia.
2.11. RED NACIONAL ACADÉMICA DE TECNOLOGÍA AVANZADA
RENATA
Dentro de las Tecnologías de la Información y Comunicaciones en Colombia se
conoce como RENATA a la red de alta tecnología que se encarga de comunicar a
varias académicas y científicas en la nación. Según la página web de RENATA
esta es administrada por una Corporación con su mismo nombre, RENATA. Esta
corporación tiene varios miembros gubernamentales y académicos del país entre
los que tenemos: las Redes Académicas Regionales, el Ministerio de Educación,
el Ministerio de Tecnologías de la Información y las Comunicaciones y
Colciencias. Según su portal web RENATA, tiene como objetivo facilitar la
comunicación y colaboración entre sus miembros.
Esta comunicación permitiría compartir temas de innovación y desarrollo
tecnológico para lograr fortalecer el desarrollo de la ciencia, la tecnología y la
38
innovación en beneficio del progreso de Colombia. (Red Nacional Académica de
Tecnología Avanzada, RENATA, 2010)
Uno de los conceptos más nombrados en este proyecto en cuanto a las redes y
las telecomunicaciones y que además tiene relación con el nombre de mismo
proyecto matriz, es el Router o Enrutador. Conocer algunas de las generalidades
que comprende este dispositivo electrónico muy utilizado en las redes de datos y
transmisión de información es importante, por lo tanto se documenta a
continuación algunos conceptos claves del funcionamiento de este equipo.
2.12. ANTECEDENTES DE LA INVESTIGACION
La necesidad de gestionar la información sobre cierto tipo de personas o grupos que tengan relación con una organización o institución determinada se ve con mayor frecuencia cuando se quiere innovar, mejorar o agilizar procesos de administración de información digital. Estos procesos informáticos de gestión de usuarios hoy en día son un área de entidad propia ya que la relación de estos con los sistemas de información y comunicaciones, es crucial a la hora de asegurar un correcto funcionamiento de los servicios puestos a la disposición de los usuarios finales, quienes se asumen tienen la capacidad y la forma de utilizarlos.
En definitiva los sistemas que trabajan con administración de usuarios finales son cada vez más grandes, robustos y sofisticados, se pueden encontrar en cualquier aplicativo web que se encuentre en internet y utilice la administración de usuarios; por lo que el desarrollo de este proyecto contiene unas bases firmes para el buen fin del proyecto.
El sistema de encolamiento será el encargado de recibir y enviar experimentos configurados en el orden de llegada de acuerdo al funcionamiento del sistema, así que es posible tomar como referencia el algoritmo FIFO, el cual consta básicamente de que “el primero que entra es el primero en salir”, muy acorde para lo deseado por el proyecto, pero desafortunadamente para este proceso no se tomará en cuenta dicho algoritmo.
También sería de mucha ayuda el sistema de encolamiento creado por Sun Microsystems “Sun Grid Engine”, el cual es un sistema de encolamiento diseñado especialmente para la conocida “Grid Computing o Computación Grid” para las granjas de computadores donde se necesitan compartir recursos al máximo y obtener el mejor rendimiento. Por lo que se descarta, ya que el aplicativo no exige tanta demanda de rendimiento.
39
El sistema de gestión de usuarios y sistema de encolamiento asemeja su trabajo a las plataformas tecnológicas las cuales se componen y se entienden como la unión entre hardware, software y comunicaciones, esto permite que el proyecto U2ROUTE tenga como base y experiencia otros proyectos previamente desarrollados, como son los siguientes:
Tanto la Universidad de Washington como la Universidad de Stanford con sus proyectos “Open Network Laboratory” y “NetFPGA” respectivamente, fueron una de las piezas bases para el inicio del proyecto U2-Route, en el cual se buscaba crear redes entre investigadores y educadores a través de la creación de sistemas avanzados, veloces y de hardware más potente.
2.12.1 Open Network Laboratory
Es un recurso para la investigación de redes y comunidades educativas, diseñadas para permitir una evaluación experimental de los conceptos de redes avanzadas en un ambiente de trabajo realista. El laboratorio está construido alrededor de código abierto extensible routers de alto rendimiento que se han desarrollado en la Universidad de Washington, y al que se puede acceder por medio de usuarios remotos a través de un Laboratorio de Interfaz Remota (Remote Laboratory Interface - RLI). El RLI permite a los usuarios configurar la red de banco de pruebas, ejecutar aplicaciones y controlar aquellas que se ejecutan utilizando el integrado de datos, reuniendo los mecanismos que los routers poseen. El RLI también permite a los usuarios ampliar, modificar o sustituir el software que se ejecuta en los procesadores de los routers embebidos para que puedan ser reconfigurados dinámicamente para soportar las nuevas capacidades. En el futuro, la RLI también permitirá a los usuarios extender de manera similar, modificar o sustituir el hardware de los routers. El RLI proporciona soporte para la visualización de datos y de pantallas remotas en tiempo real, permitiendo a los usuarios desarrollar los conocimientos necesarios para comprender el comportamiento de nuevas capacidades dentro de un ambiente operativo complejo. (Wiseman, Turner, DeHart, Parwatikar, & Wong, 2009)
2.12.2 NetFPGA
El Proyecto NetFPGA se refiere a un esfuerzo para desarrollar un hardware de fuente abierta y plataforma de software para permitir una rápida creación de prototipos de dispositivos de red. El proyecto se dirige principalmente a
40
investigadores académicos, usuarios de la industria, y también a los estudiantes en el aula. Aunque no es la primera plataforma de este tipo en la comunidad de redes, NetFPGA se distingue principalmente en dos formas. En primer lugar se encuentra en su enfoque basado en FPGA para prototipos dispositivos de red. Esto permite a los usuarios desarrollar diseños que son capaces de procesar paquetes a line-rate, una capacidad general que no ofrecen los enfoques basados en software. La segunda característica que podemos distinguir del NetFPGA, es que se centra en el apoyo de una comunidad de hardware de código abierto y desarrolladores de software que puedan compartir y aprovechar los demás proyectos y la construcción de bloques IP. (NetFPGA, 2010) El proyecto comenzó en 2007 como un proyecto de investigación en la Universidad de Stanford, con lo que se llamó la NetFPGA-1G. "La 1G", como se le conoce coloquialmente, fue diseñado originalmente como una herramienta para la educación para enseñar a los estudiantes acerca de arquitectura de hardware para redes y diseño. La plataforma 1G consistió en una tarjeta PCI con un Xilinx Virtex-II Pro FPGA y 4 interfaces de 1GigE, junto con un código para descargar archivos del repositorio que contiene una biblioteca IP y algunos ejemplos de algunos diseños. El proyecto fue creciendo y al final de 2010 más de 1.800 tablas de 1G habían sido vendidas a más de 150 instituciones educativas que abarcan 15 países. Durante ese crecimiento de la 1G no sólo ganó popularidad como una herramienta para la educación, sino también como una herramienta para la investigación. Para el año 2011 más de 46 artículos académicos se han publicado sobre la investigación que utiliza la plataforma NetFPGA-1G. Además, más de 40 proyectos han contribuido y han sido incluidos en el código 1G del repositorio de fin de año 2010. (Blott, Ellithorpe, McKeown, Vissers, & Zeng, 2010)
41
3. MARCO METODOLÓGICO
A continuación se encuentra la metodología (Reyes & Sabino, 1999) que se usó para realizar el presente Proyecto de Investigación. Se presentarán aspectos como el tipo de investigación, las técnicas y procedimientos que se llevaron a cabo para efectuar dicha investigación.
3.1. NIVEL DE INVESTIGACIÓN DEL DESARROLLO SOFTWARE De acuerdo al problema referido al Módulo de Administración de Usuarios, Histórico de Pruebas y Sistema de Encolamiento de un Laboratorio Remoto utilizando un Router Reprogramable, la investigación fue de tipo Exploratoria, la cual según (Kotler & Armstrong, 2006) es aquella que se efectúa sobre un tema u objeto poco conocido o estudiado, por lo que sus resultados constituyen una visión aproximada de dicho objeto. Acorde a esta modalidad de investigación se realizaron 3 fases en el estudio, a fin de cumplir con los requisitos que se presentan en la Investigación Exploratoria. En la primera fase inicialmente se realizó una búsqueda sobre aquellos proyectos similares y toda información que de alguna u otra manera estaba relacionada con los Módulos anteriormente mencionados, a fin de conocer los conceptos necesarios para el inicio del proyecto. En la segunda fase se presentaron una serie de propuestas de cada Módulo por parte de cada uno de los participantes con el fin de corregir errores y mejorar ideas. Finalmente en la tercera fase, atendiendo a los resultados de la presentación de las propuestas se procede a crear la estructura del funcionamiento del sistema. 3.2. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE ANTECEDENTES DE INFORMACIÓN Las técnicas de recolección de antecedentes usadas para obtener información con el fin de conseguir un conocimiento más amplio de la realidad de la problemática acerca del proyecto U2ROUTE han sido de análisis documentales, utilizando referencias bibliográficas y como también referencias en la web que aportaron para el análisis, los requerimientos, el diseño y construcción de dicho proyecto.
42
Las entrevistas fueron participes en este proceso de investigación realizadas con el personal de la Universidad Pontificia Bolivariana con las cuales se está desarrollando este proyecto, estas a su vez generaron ayudas y mejoras para continuar con este proceso. 3.3. TÉCNICAS DE PROCESAMIENTO Y ANÁLISIS DE DATOS Las técnicas utilizadas para analizar la información obtenida durante el proceso de investigación para brindar la solución más adecuada al proyecto U2ROUTE, se llegaron a un acuerdo de manera grupal, es decir se realiza una reunión entre los integrantes del grupo de investigación, se llega a un consenso de que documentos o información se debe utilizar. También es necesario tener en cuenta lo que debe llevar el informe escrito y demás procesos acordes a la investigación. Para que al momento de la respectiva revisión los cambios no afecten demasiado el desarrollo del proyecto. 3.4. METODOLOGÍA PARA EL DESARROLLO El desarrollo propuesto se adecuo a los procesos de investigación documental, la cual se basa en la obtención y análisis de datos provenientes de materiales impresos u otros tipos de documentos. Se emplearon una serie de instrumentos y técnicas de recolección de información. Para ello hubo que cumplir con tres etapas, la primera está referida con la delimitación del objeto de estudio y la elaboración del marco teórico, la segunda etapa implicó la identificación de las variables y la relación entre las mismas y la tercera etapa correspondió a plantear una versión inicial del módulo, para luego depurarlo y generar resultados. 3.5. METODOLOGÍA PARA LAS PRUEBAS DEL SOFTWARE
El plan de pruebas tiene como objetivo descubrir posibles defectos en sus funciones principales al momento de su funcionamiento. Este proceso de plan de pruebas tiene dos objetivos los cuales son:
Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.
Descubrir los defectos en el comportamiento del sistema, si no es deseable o no cumple con su especificación.
El primero especifica que debe existir al menos un proceso de prueba para cada requerimiento del sistema y del usuario. Este objetivo conduce a la realización de
43
pruebas de validación en las cuales se espera un resultado de su correcto funcionamiento usando un conjunto determinado de casos de prueba. El otro objetivo define la eliminación de todos los comportamientos no deseables por el sistema, en este caso la plataforma web para el laboratorio remoto del proyecto U2ROUTE. Esto se puede realizar mediante casos de prueba que se diseñan para exponer los defectos que se encuentren y solucionarlos. Las pruebas demuestran que el software no está libre de defectos o que se comportará de manera cómo está especificado, generalmente por lo tanto el objetivo de los planes de pruebas es convencer a los desarrolladores y al usuario final de que el sistema es el adecuado y suficientemente bueno para su uso operacional ya que para la plataforma web es vital tener una buena disponibilidad del sistema, un buen repositorio de la información y un manejo adecuado de toda esta información.
3.5.1. Diseño de casos de prueba
Es una parte del plan de pruebas que se compone de las pruebas de sistemas y pruebas de componentes con el fin de evaluar las entradas y salidas esperadas que contiene la plataforma en el módulo de administración de usuarios. El objetivo de este diseño es crear un conjunto de pruebas que sean efectivos descubriendo defectos en el programa y mostrando que el sistema satisface las necesidades de los requerimientos. Para definir este diseño se define una característica del sistema, es decir una característica del módulo.
Teniendo en cuenta lo anterior, la metodología que se manejó en el desarrollo del
proceso debe satisfacer los siguientes ítems:
Identificar las fuentes de información oficiales que brindan datos sobre proyectos similares.
Seleccionar la información de interés de dichas fuentes.
Identificar las variables que vamos a identificar en el módulo.
Establecer las relaciones entre las variables.
Plantear una versión inicial del módulo.
Depurar el modulo.
Generar datos (simulaciones).
Documentar los procesos realizados.
Plantear conclusiones y recomendaciones.
44
4. DESARROLLO DEL PROYECTO
4.1. DESCRIPCIÓN DEL PROBLEMA
Módulo de administración de usuarios
Con el surgimiento del Proyecto U2ROUTE, no existe la posibilidad de administrar
de forma ordenada la información de los usuarios que deseen realizar pruebas de
Laboratorio de forma remota por medio de RENATA. No existen procesos
coherentes que permitan conocer como los usuarios interactúan con dicho
sistema.
Es difícil para el usuario tener un acceso a los diferentes módulos del proyecto
U2ROUTE de manera conjunta, esto genera que el usuario no pueda obtener los
resultados de sus pruebas ya que no hay forma de que estas le sean asignadas.
Lo anterior conlleva a que el sistema web no sea seguro, administrable y
organizado, generando poca credibilidad y desconfianza entre los usuarios sobre
el uso de este sistema.
Algoritmo de Encolamiento
Para poder llevar a cabo la ejecución de los experimentos que los usuarios configuran en la plataforma, se encuentra la necesidad de desarrollar un aplicativo que reciba una prueba configurada en la interfaz web que maneja el usuario y que esta posteriormente, sea enviada para que sea encolada teniendo en cuenta orden de llegada y prioridad de dichas pruebas.
Para explicar de forma más sencilla este proceso se debe tomar un ejemplo de la fila para el banco. Existe la posibilidad de atender primero, no a los usuarios normales del banco que llegaron de primeros, sino a los clientes preferenciales de este sin importar si llegaron después que el usuario normal, pero también teniendo en cuenta que por cada dos o tres clientes preferenciales que se atiendan, se atenderá un usuario normal.
Ahora bien, este sistema debe contener un parámetro modificable por parte del Administrador, es decir, que el Administrador pueda definir cuantos experimentos locales desea que se ejecuten por cada experimento foráneo. Para permitir al Administrador tener un mejor manejo de la plataforma, es
necesario hacer uso de un Log de actividades, donde se pueda encontrar
45
información acerca del número de experimentos enviados, la hora y el código del
usuario y el tipo de prueba.
4.2. FORMULACIÓN DEL PROBLEMA
Módulo de administración de usuarios
Se requiere de un aplicativo que permita al usuario consultar y modificar su perfil,
además de poder configurar un experimento en forma remota, sin necesidad de
contar con el dispositivo de manera física en el momento, igualmente que posibilite
la visualización de los resultados de dicho experimento mediante el acceso a un
repositorio de pruebas. Se desea que dicho aplicativo de Administración de
Usuarios sea accesible a través de Internet (World Wide Web).
El aplicativo debe contener en su pantalla principal un mensaje de bienvenida que
presente información sobre las instituciones que participaron en la realización del
proyecto, al igual que una breve introducción que describa los servicios ofrecidos
junto con la opción para Iniciar Sesión.
Para que un usuario pueda tener acceso a la plataforma web, debe enviar una
carta con sus datos (Nombre, Dirección, Email de Organización a la que
pertenece, Nombre de la Profesión que tiene, Nombre, Apellido, Cedula, Email y
Grupo de Investigación) e igualmente debe registrarse en dicha plataforma, para
que posteriormente el Administrador del Sistema active su cuenta confrontando la
información enviada por correo tradicional; posterior a este procedimiento, el
usuario será clasificado en “foráneo” o “local” según la institución a la que
pertenezca.
Para que el usuario pueda hacer uso del Laboratorio Remoto U2ROUTE debe
acceder por medio de la inserción de un usuario previamente especificado, una
contraseña previamente escogida (mínimo 8 y máximo 20 caracteres) y que deben
ser validados exitosamente.
Al ingresar en la plataforma, el usuario encontraría tres (3) apartados con los
cuales interactuar: Perfil, Experimento, Resultados. Los ingenieros de desarrollo
de la Universidad Católica de Pereira, solo serían responsables por el análisis,
diseño e implementación para brindar el acceso necesario al usuario a dichos
módulos.
46
En la sección „Perfil‟ deben permitirse la visualización de dos (2) segmentos: Perfil
y Publicaciones, donde el usuario podrá modificar su información personal, su
contraseña y actualizar los datos de sus publicaciones en la plataforma.
El Administrador de la plataforma podrá tener acceso, tanto a la gestión de su
información personal como también al log de acceso y acciones de un usuario
específico.
Algoritmo de encolamiento
El algoritmo del sistema de encolamiento para el proyecto requiere recibir una prueba configurada en la interfaz web que maneja el usuario y que posteriormente envía para que el sistema encole la prueba, pero no es así de sencillo, ya que se requiere atender por orden de llegada y prioridad dichas pruebas.
Para explicar de forma más sencilla este proceso se retomará el ejemplo de la fila para el banco. Existe la posibilidad de atender primero no a los usuarios normales del banco que llegaron de primero sino a los clientes preferenciales de este sin importar si llegaron después que el usuario normal pero también teniendo en cuenta que por cada dos o tres clientes preferenciales que se atiendan, se atenderá un usuario normal.
Ahora bien, el sistema de encolamiento contiene dos funciones importantes una de estas consta del algoritmo de prioridad el cual permitirá trabajar de manera secuencial y ordenada los experimentos que se deseen trabajar por parte de los usuarios finales que accedan al proyecto U2ROUTE, este algoritmo se construye básicamente en el Lenguaje de Programación PHP, trabajando con la herramienta Software NetBeans V 6.9 sobre un Sistema Operativo Windows 7 Home Premium. Este algoritmo dentro de su función de priorizar los experimentos configurados en la plataforma también los organiza dentro de una base de datos la cual fue construida en PostgreSQL. Para el desarrollo evolutivo de este algoritmo de encolamiento se realiza un primer código el cual solo priorizaba dos pruebas locales por una foránea es decir solo cumplía con ese requerimiento, luego con base en unos cambios realizados este parámetro es modificable por parte del Administrador, es decir, el Administrador puede definir cuantos Experimentos Locales desea que se ejecuten por Experimentos Foráneos. Es posible igualmente visualizar un Log (Registro) de cuantos experimentos han sido enviados, la hora y el código del usuario y el tipo de prueba, todo esto se guarda en un archivo “.txt” en la carpeta donde se encuentran alojados los
47
archivos “.php” que le permiten al Administrador hacer toda esta configuración (en la primera versión), en su evolución se decidió guardar el log en la base de datos para permitir filtrar en un futuro dicha información. Se requiere también que cuando se configura un experimento estos archivos deben ser copiados en una carpeta en nuestro servidor de manera comprimida y luego deben ser extraídos en esa carpeta, para esto se generan tres archivos de extensión “.php” los cuales se llaman “comprimir.php”, “copiar.php” y “descomprimir.php”. Para revisar los experimentos a ser reportados, se realizaran consultas a la base de datos cada minuto, allí se debe identificar el ámbito a manejar (Foránea o Local), se busca un experimento que no haya sido reportado que cumpla con ámbito definido, si se encuentra se reporta, si no, busca el ámbito contrario y si lo encuentra lo reporta. Estos contienen cada una de sus funciones como su nombre lo indica para realizar las pruebas piloto (de prueba), con el fin de crear todo de manera más fácil para un mejor entendimiento y luego unir todo esto de manera secuencial para obtener el resultado esperado, cabe decir que existe un archivo en PHP que realiza las funciones de copiar y comprimir en formato TAR.GZ, hasta el momento solo falta unir los tres procesos anteriores al código del Algoritmo de Prioridad donde realmente van a trabajar. Se debe tener en cuenta que para poder copiar, comprimir y descomprimir un
archivo es necesario tener un archivo existente con sus parámetros
correspondientes, así que en este caso se deben realizar consultas cruzadas a la
base de datos para realizar de la mejor manera este proceso y evitar la pérdida de
información.
4.3. ANÁLISIS
La etapa de análisis correspondiente al proyecto U2ROUTE tomará como base el
capítulo 7, Modelo de Análisis del Libro Ingeniería del Software Orientada a
objetos con UML, JAVA e Internet del Autor Alfred Weitzenfeld. En este capítulo se
describe los procesos que se deben llevar a cabo en esta etapa tan importante
para un desarrollo de software bien estructurado.
48
La metodología clásica permite basarse en definiciones de diferentes autores por
esta razón se utilizará el modelo de análisis de Weitzenfeld para la etapa
anteriormente descrita.
Después de obtener los requerimientos (ver ANEXO 1 – FORMATO DE
REQUERIMIENTOS) necesarios para el proyecto, se realiza el análisis del
sistema mediante la creación de diagramas UML y un modelo Vista Controlador el
cual es definido por el autor para permitir un mejor entendimiento de los casos de
uso.
49
4.3.1. Diagrama de casos de uso del módulo de administración de usuarios.
Figura 7: Diagrama de casos de uso del módulo de administración de usuarios.
Fuente: Elaboración propia
50
DESCRIPCIÓN DE ACTORES DEL DIAGRAMA DE CASOS DE USO.
Actor Usuario
Casos de Uso Consulta y Modificación de Perfil. Iniciar Sesión. Configurar Experimento. Visualización de Resultados Repositorio de Pruebas
Tipo Primario
Descripción Este actor es el que interactúa y ejecuta los procesos básicos de la plataforma
Tabla 1: Actor usuario
Fuente: Elaboración propia
Actor Administrador del Sistema
Casos de Uso Iniciar Sesión Desactivar Usuarios Consultar – Modificar Info. Usuarios CRUD Profesiones CRUD Organizaciones Configuración del Sistema de Encolamiento Acceso a Registros Consulta y Modificación de Perfil
Tipo Primario
Descripción Gestiona la información dentro de la plataforma, configura y ejecuta procesos dentro de la misma.
Tabla 2: Actor Administrador del sistema
Fuente: Elaboración propia
Actor Base de Datos
Casos de Uso Almacenar Información Entregar Información Iniciar Sesión
Tipo Primario
Descripción Permite gestionar y almacenar la información experimental.
Tabla 3: Actor base de datos Fuente: Elaboración propia
51
A continuación se presentan las especificaciones de los Casos de Uso del diagrama.
DESACTIVAR USUARIOS
Descripción Preliminar: Este caso de uso permite desactivar los usuarios de la base de datos que se vayan a dar de alta del sistema de la base de datos del proyecto U2-Route, que ya no pertenezcan a X proyecto investigativo.
Actor: Administrador del Sistema. Pre-Condiciones: El usuario que realizará la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos o Administrador del Sistema. El usuario debió enviar una carta solicitando darse de baja dentro del sistema. Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho sobre el usuario, entre esas no permitir el ingreso del usuario a la plataforma.
Excepciones:
Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
CONSULTAR – MODIFICAR USUARIOS.
Pre-Condiciones: El usuario que realizará la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos o Administrador del Sistema. El usuario debió enviar una carta de solicitud de registro y en ella debe estar especificado si es o no es líder. Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho sobre el catálogo de Usuarios del proyecto.
52
Excepciones:
Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
Imágenes Asociadas al Caso de Uso
Figura 8: Consultar y Modificar Usuarios. Fuente: Elaboración propia.
Figura 9: Consultar y Modificar Usuarios
Fuente: Elaboración propia.
53
CRUD PROFESIONES
Descripción Preliminar: Este caso de uso permite administrar todas las profesiones de los usuarios que estarán vinculados al proyecto U2-Route, con el fin de realizar un registro más detallado de las los mismos.
Actor: Administrador del Sistema.
Pre-Condiciones: El usuario que realizara la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos o Administrador del Sistema. Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho sobre el catálogo de Profesiones del proyecto.
Excepciones: Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
Imágenes Asociadas al Caso de Uso
Figura 10: CRUD Profesiones.
Fuente: Elaboración propia.
54
Figura 11: CRUD Profesiones
Fuente: Elaboración propia.
CRUD ORGANIZACIONES
Descripción Preliminar: Este caso de uso permite administrar la información de todas las organizaciones que estarán vinculadas al proyecto U2-Route, con el fin de realizar un registro más detallado de las los usuarios.
Actor: Administrador del Sistema. Pre-Condiciones: El usuario que realizara la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos o Administrador del Sistema. El líder de la Institución debe enviar una carta al Administrador de Proyectos o Administrador del Sistema para la solicitud de registro de la Institución en el sistema teniendo en cuenta que un líder puede solo registrar una Institución. Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho sobre el catálogo de Organizaciones del proyecto.
Excepciones: Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato
55
esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
Imágenes Asociadas al Caso de Uso
Figura 12: CRUD Organizaciones.
Fuente: Elaboración propia.
Figura 13: CRUD organizaciones 2.
Fuente: Elaboración propia.
56
CONFIGURACIÓN DEL SISTEMA DE ENCOLAMIENTO
Descripción Preliminar: Este caso de uso permite al administrador configurar el número de pruebas locales que el Sistema de Encolamiento permitirá encolar dado su algoritmo de prioridad.
Actor: Administrador del Sistema. Pre-Condiciones: El usuario que realizará la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos o Administrador del Sistema. Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho para que el Sistema de Encolamiento funcione correctamente.
Excepciones:
Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
Imágenes Asociadas al Caso de Uso
Figura 14: Configuración del Sistema de Encolamiento
Fuente: Elaboración propia.
57
ACCESO A REGISTROS
Descripción Preliminar: Este caso de uso permite al administrador acceder a los registros que involucren los movimientos en la plataforma.
Actor: Administrador del Sistema. Pre-Condiciones: El usuario que realizará la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos o Administrador del Sistema. Debe existir movimiento en la plataforma por parte de los usuarios del proyecto U2ROUTE. Post-Condiciones: La información debe quedar en la base de datos, es decir los logs de registro de movimientos en la plataforma.
Imágenes Asociadas al Caso de Uso
Figura 15: Acceso a Registros.
Fuente: Elaboración propia.
58
CONSULTA Y MODIFICACIÓN DE PERFIL
Descripción Preliminar: Este caso de uso permite a cualquier usuario registrado en la plataforma poder visualizar y modificar su información, con el fin de tener información más detallada de las mismas.
Actor: Administrador del Sistema, Usuario Pre-Condiciones: El usuario que realizará la operación se encuentra validado en el sistema con perfil de Administrador de Proyectos, Administrador del Sistema o Investigador. Si el caso es de Modificación de Datos, estos deben ser validados. Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho sobre el catálogo de Usuario de un proyecto determinado.
Excepciones: Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
Imágenes Asociadas al Caso de Uso
59
Figura 16: Consultar y Modificar Perfil
Fuente: Elaboración propia.
Figura 17: Consultar y Modificar Perfil 2
Fuente: Elaboración propia.
60
Figura 18: Consultar y Modificar Perfil 3
Fuente: Elaboración propia.
Figura 19: Consultar y Modificar Perfil 4
Fuente: Elaboración propia.
61
Figura 20: Consultar y Modificar Perfil 5
Fuente: Elaboración propia
INICIAR SESIÓN
Descripción Preliminar: Este caso de uso permite a cualquier usuario registrado en la plataforma poder ingresar a la plataforma.
Actor: Administrador del Sistema, Usuario Pre-Condiciones: El usuario que realizará la operación se encuentra registrado en la base de datos del sistema sea como Administrador de Proyectos, Administrador del Sistema o Investigador. Post-Condiciones: El Administrador de Proyectos, Administrador del Sistema o Investigador iniciaron sesión en el sistema correctamente.
Excepciones:
Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
Imágenes Asociadas al Caso de Uso
62
Figura 21: Iniciar Sesión.
Fuente: Elaboración propia.
REGISTRAR USUARIO
Descripción Preliminar: Este caso de uso permite a cualquier usuario registrarse en la plataforma U2ROUTE.
Actor: Usuario Pre-Condiciones: El usuario debe haber ingresado a la página principal y dar clic en “Registrarse” Post-Condiciones: La información debe quedar en la base de datos, es decir los cambios que se hayan hecho sobre el catálogo de Usuario de un proyecto determinado.
Excepciones:
Las excepciones se lanzarán cuando las validaciones de los datos no sean correctas, bien sea por el tipo de dato, es decir que no corresponde al tipo de dato esperado, ejemplo: un elemento de tipo cadena en lugar de un dato tipo entero; o porque dicho campo del dato se encuentre nulo.
63
Imágenes Asociadas al Caso de Uso
Figura 22: Registrar Usuario.
Fuente: Elaboración propia.
ALMACENAR INFORMACIÓN
Descripción Preliminar: Permite el almacenamiento de toda la información manejada en la plataforma web (configuración de pruebas, información de usuarios, proyectos, resultado de las pruebas).
Actor: Base de Datos. Pre-Condiciones: Se debe gestionar una correcta comunicación entre la lógica de presentación, negocio y la base de datos. Post-Condiciones: Información almacenada de manera persistente y correcta. MOSTRAR INFORMACIÓN
Descripción Preliminar: Permite entregar toda la información manejada en la
64
plataforma web (configuración de pruebas, información de usuarios, proyectos, resultado de las pruebas).
Actor: Base de Datos.
Pre-Condiciones: Se debe gestionar una correcta comunicación entre la lógica de presentación, negocio y la base de datos. Post-Condiciones: Información presentada en la plataforma. CONFIGURAR EXPERIMENTO
Descripción Preliminar: Este caso de uso permite ingresar al módulo de configuración de experimentos.
Actor: Usuario
Pre-Condiciones: El usuario que realizará la operación se encuentra validado en el sistema con perfil de Investigador. Los datos de configuración de prueba deben ser correctos. Post-Condiciones: La información debe quedar en la base de datos, es decir la configuración del experimento que se haya realizado para ser ejecutado remotamente. REPOSITORIO DE PRUEBAS
Descripción Preliminar: Permite ver información de proyectos de la institución o los que estén permitidos de otras instituciones.
Actor: Usuario
Pre-Condiciones: El usuario que realizará la operación se encuentra validado o no en el sistema con perfil de Investigador. Las pruebas solo podrán ser visualizadas si esta información es propia del usuario en el caso de que se hallan definido como privadas.
65
El usuario no validado (invitado) solo podrá ver las pruebas definidas como públicas. Post-Condiciones: Visualización de la información de los proyectos.
4.3.2. Diagrama de caso de uso para el sistema de encolamiento
Figura 23: Diagrama de casos de uso para el sistema de encolamiento.
Fuente: Elaboración propia
A continuación se presentan las especificaciones de los Casos de Uso.
ORDENAR LISTA DE EJECUCIÓN DE EXPERIMENTOS
Descripción Preliminar: Este caso de uso permite ordenar la lista de experimentos a ejecutar, por medio de un parámetro impuesto por el Administrador del Sistema el cual es el número de pruebas locales.
El número de pruebas foráneas se encuentra establecido como un valor fijo y su valor es 1.
Actor: Algoritmo de Prioridad y Administrador del Sistema. Pre-Condiciones: El administrador del sistema estableció el parámetro de encolamiento para que el algoritmo de prioridad realizara el ordenamiento automático de las pruebas, si y solo si ya se han configurado pruebas.
66
Post-Condiciones: El Algoritmo de prioridad debe ordenar los experimentos automáticamente.
ENVIAR EXPERIMENTO AUTOMÁTICAMENTE.
Descripción Preliminar: Este caso de uso permite enviar los experimentos automáticamente para que sean desarrollados en el laboratorio remoto.
Actor: Algoritmo de Prioridad. Pre-Condiciones: La prueba debió haber sido configurada y encolada posteriormente por el algoritmo de prioridad. Post-Condiciones: Prueba enviada y ubicada en el servidor.
VER LOGS DE RESULTADOS.
Descripción Preliminar: Este caso de uso permite al administrador del sistema ver los logs (registros) del sistema, es decir, conocer los experimentos enviados y recibidos.
Actor: Algoritmo de Prioridad. Pre-Condiciones: La prueba debió haber sido configurada, encolada posteriormente por el algoritmo de prioridad y enviada al servidor o recibida del servidor. Post-Condiciones: Logs de pruebas enviadas o recibidas visualizadas gracias a la información guardada en la base de datos.
COPIAR COMPRIMIR DESCOMPRIMIR.
Descripción Preliminar: Este caso de uso permite comprimir y copiar la carpeta que contiene la información de la configuración de la prueba, ubicarla en el servidor y descomprimirla después para su ejecución.
Actor: Sistema
67
Pre-Condiciones: La prueba debió haber sido configurada, encolada posteriormente por el algoritmo de prioridad y enviada al servidor. Post-Condiciones: Carpeta descomprimida para ser ejecutada la prueba.
CONSULTAR BASE DE DATOS.
Descripción Preliminar: Este caso de uso permite consultar la base de datos para verificar cambios en la misma, y así detectar el momento adecuado para enviar un experimento configurado.
Actor: Sistema Pre-Condiciones: El servicio debió haberse activado automáticamente. Post-Condiciones: Consultas continúas a la base de datos.
4.3.3. Diagrama de Flujo del Algoritmo de prioridad para el Sistema de
Encolamiento
Figura 24: Proceso Inicial y Proceso 2
Fuente: Elaboración Propia
68
Figura 25: Proceso 1
Elaboración Propia
69
Figura 26: Proceso 3
Elaboración Propia
70
Figura 27: Proceso 4
Elaboración Propia
71
4.3.4. Modelo vista-controlador (MVC) referente a los casos de uso planteados
Figura 28: MVC Registro de usuario.
Fuente: Elaboración propia
72
Figura 29: MVC Iniciar Sesión.
Fuente: Elaboración propia
73
Figura 30: MVC Configuración y modificación de perfil.
Fuente: Elaboración propia
74
Figura 31: MVC Configuración de experimento.
Fuente: Elaboración propia
75
Figura 32: MVC Entrega de información.
Fuente: Elaboración propia
76
Figura 33: MVC Reporte de experimentos.
Fuente: Elaboración propia
77
4.3.5. Diagrama entidad relación del sistema.
A partir de la definición del problema planteada se desarrolló el siguiente diagrama
ER, descrito de la siguiente manera:
Relaciones:
- usuarios – configura – experimentos:
Un usuario puede configurar muchos experimentos. La entidad
experimentos no fue creada por nosotros.
- usuarios – tiene – profesión
Muchos usuarios tienen una misma profesión. Si bien una persona
puede tener varias profesiones aquí en este sistema solo se necesita
que registre una.
- usuarios – pertenecen – organización
Muchos usuarios pueden pertenecer a una misma organización
- usuarios – pertenece – log
A un usuario le pertenece una entidad que contiene información de
páginas de acceso al sistema y acciones en el sistema.
- organización – pertenecen – log
A una organización le pertenecen los logs de los usuarios que
pertenecen a esta. Es un requerimiento a petición de que se pudiera
conocer en la base de datos el log por Organizaciones.
- experimentos – pertenece – files
A un experimento le pertenece un archivo en disco. La entidad files no
fue creada por nosotros, es una entidad que guarda las propiedades del
archivo que pertenece al experimento.
- experimentos – pertenece – log_sisencola
A un experimento le pertenece un log. Creado para el sistema de
encolamiento, permite conocer el orden de envío de los experimentos,
igualmente; el orden en el que se reciben los resultados ya que se
78
reciben en el mismo orden en que se envían por cómo está diseñado el
sistema de encolamiento.
Entidades:
- contador_experimento: Esta entidad permite guardar la configuración del
sistema de encolamiento, también se usa para el log de configuraciones.
- log_sisencola: Es una entidad que guarda las acciones del sistema de
encolamiento.
- experimentos: En esta entidad en la que se guarda varia información, es
solo del interés de nosotros la que usa el sistema de encolamiento, como el
estado, cedula_usuario, path_1, path_2 y id_experimento. Estos para
identificar cual experimento se debe enviar, a quien pertenece y en donde
está el archivo a enviar.
- usuarios: Entidad que guarda la información del usuario. Información de
contacto, usuario, password, rol (usuario, administrador, invitado), el estado
de la cuenta (activada, desactivada), a que organización pertenece y que
profesión ejerce.
- profesión: información de las diferentes profesiones registradas en el
sistema.
- organización: información de contacto de la organización y el tipo de
organización en cuanto al sistema (organización local o foránea al
proyecto).
- log: Información de acceso y acciones en el Sistema de administración de
usuarios, diseñada para ver por usuario o por organizaciones.
79
Figura 34: Diagrama entidad-relación del sistema.
Fuente: Elaboración propia
80
4.3.6. Definición de la interfaz de usuario.
A continuación se presenta una descripción a nivel general de la interfaz de
usuario del proyecto.
Elementos Descripción Definición
Títulos Principales Etiqueta principal que llevara cada categoría acompañado del icono representativo del proyecto.
Tamaño: 14 Color: negro Letra: Arial
Fondo grafico Papel tapiz del sistema web
Tamaño: 1080x1024
Texto Introducción Descripción del Proyecto que se encontrará en la página principal
Tamaño: 12 Color: negro Letra: Times New Roman Cursiva
Logo Encabezado Gráfico que distingue el proyecto.
Tamaño: 948x168
Logo para títulos Principales
Gráfico principal a escalas menores para acompañar títulos de etiquetas principales
Tamaño: 190x35
Texto base Texto de subtítulos. Tamaño: 12 Letra: Arial Color: Negro
Texto Excepciones Texto de excepciones ejecutadas por errores
Tamaño:12 Letra: Arial Color: Azul
Campo de video Espacio para ubicación de video sobre el proyecto U2-Route
Tamaño:
81
Figura 35: Definición de la interfaz de usuario.
Fuente: Elaboración propia
4.3.7. Definición de plan de pruebas
El modelo de pruebas para el proyecto U2ROUTE se encuentra basado en el en el
Capítulo 10 del libro Ingeniería de Software Orientado a Objetos con UML, JAVA e
Internet de Alfredo Weitzenfeld, este capítulo describe los tipos de prueba que
existen, cuales se deben aplicar al proyecto que se está realizando, etc.
Las pruebas a realizar sobre el sistema Web U2ROUTE son pruebas de
requisitos, de caso de uso, ergonómicas, de documentación de usuario y pruebas
de aceptación o validación, teniendo en cuenta los niveles de pruebas de
integración con el fin de verificar, tomando como punto de vista el usuario final, los
82
casos de prueba establecidos y la estrategia de alcance de pruebas, identificando
el tipo, número y los casos de prueba que se aplicarán para revisar los diferentes
aspectos del sistema, como se explica en el apartado del Plan de Pruebas del
marco teórico.
4.4 DISEÑO
4.4.1 Arquitectura del Sistema
Una de las ventajas principales es que el desarrollo se puede particionar en varios niveles, dado el caso que se presente algún problema y algún modulo deba ser modificado. Esta arquitectura tiene 3 capas.
a. Capa de Presentación Esta es la capa que ve el usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo proceso. También es conocida como Interfaz gráfica y debe ser amigable al usuario, ya que esta se conecta con la capa de negocio.
b. Capa de Negocio Aquí es donde se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina de esta manera porque es donde se establecen todas las reglas que debe cumplir el aplicativo. Esta capa se comunica con la de presentación, para recibir las solicitudes y presentar resultados posteriormente, y luego con la capa de datos, para solicitar al gestor de base de datos para almacenar, recuperar o solicitar datos en él.
c. Capa de Datos Es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos y son los encargados de realizar el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
83
4.4.2 Lenguaje de Modelación Visual UML
Los casos de uso anteriormente mencionados, se realizaron bajo los Lenguajes de Modelación Visual UML serán sumamente importantes para el análisis, diseño e implementación de la plataforma de administración de usuarios y algoritmo de encolamiento.
4.4.3 Sistema de Gestión de Bases de Datos
Para construir un módulo de administración de usuarios se debe tener muy claro cómo funciona un sistema de gestión de bases de datos sus componentes y sus principales objetivos como seguridad, consistencia y abstracción, entre otros. Se puede usar cualquiera de estos gestores que se mencionan a continuación: Microsoft SQL Server 2000, MySQL, Oracle que son comerciales y SQLite, FireBird, PostgreSQL que son libres, entre otros. Para la construcción de sistemas de grandes dimensiones se propone PostgreSQL 9.0 por las características que a continuación se mencionan:
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente.
Es el sistema de gestión de bases de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la estabilidad del sistema.
Un fallo en uno de los procesos no afectará el resto y el sistema continuará funcionando.
4.4.4 Identificación del Alcance Tecnológico
Requisitos tecnológicos
o Firewall: El firewall hace parte de la topología de red de la aplicación web
el cual protege los servidores de ataques informáticos o de malware alojado en la red.
o Servidor web: Este servidor es el encargado de alojar el aplicativo por
medio de un servicio conocido como apache, para este servidor se
84
recomienda un sistema operativo Linux para mejorar las políticas de defensa.
o Servidor base de datos: Es el servidor en el cual estará alojada la base
de datos, la cual podrá estar montada en el sistema gestor, en nuestro caso Postgresql.
o Internet: En este caso será un canal de acceso para las personas que no
se encuentren en la red académica RENATA.
Figura 36: Alcance Tecnológico.
Fuente: Elaboración Propia.
4.4.5 Identificación de los usuarios participantes y finales
Catálogo de usuarios Módulo de Administración de Usuarios
USUARIO FUNCIONES Lo que requiere del sistema
Administrador
Administrar la base de
datos.
Brindar soporte a los
Es el encargado de mantener disponible la base de datos y el aplicativo, además debe brindarle
85
diferentes usuarios.
Modificar información
cuando la situación lo
amerite.
Modificar perfiles e
inactivar usuarios.
soporte a los usuarios dándole solución a sus requerimientos. En sus obligaciones está la de activar los usuarios nuevos que se registren en la aplicación y de cambiar el estado de un usuario cuando este sea desactivado del sistema.
Usuario
Visualizar resultados de sus experimentos
Configurar experimentos
Modificar parte de su información.
Los usuarios pueden iniciar sesión y acceder a la web para visualizar los resultados de sus proyectos y configurar experimentos.
Tabla 4: Catalogo de usuarios del módulo de administración de usuarios
Fuente: Elaboración propia
Catálogo de usuarios Sistema de Encolamiento
USUARIO FUNCIONES Lo que requiere del sistema
Administrador Establecer el número de pruebas locales por las cuales se enviara una foránea.
Es el encargado de configurar el algoritmo de prioridad estableciendo un número de pruebas locales y foráneas, para realizar el encolamiento correctamente. Igualmente, es el encargado de revisar los registros de las actividades realizadas en el sistema de encolamiento.
Algoritmo de Prioridad Ordenar la lista de ejecución de experimentos.
Este algoritmo permite gestionar el orden en el que se ejecutaran las pruebas de manera
86
Enviar experimentos automáticamente.
automática, detectando el momento adecuado para enviar el experimento configurado.
Sistema Activar su funcionamiento automáticamente.
Consultar la base de datos y verificar cambios.
Detectar la llegada de los resultados.
El sistema debe activarse automáticamente, ejecutar los procedimientos respectivos para el envío de pruebas e igualmente consultar cada un periodo determinado la base de datos para encontrar cambios y detectar los resultados oportunamente
Tabla 5: Catálogo de usuarios sistema de encolamiento
Fuente: Elaboración propia
87
4.4.6 Modelo Físico de Datos
Figura 37: Modelo Físico de Datos.
Fuente: Elaboración Propia.
88
4.4.7 Metadatos
Usuarios
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Experimentos
Atributos Tipo Longitud Descripción
nombre A 40 nombre del usuario
apellido A 40 apellidos del usuario
password A 40 contraseña de acceso al sistema web
email A 40 correo del usuario
grupo_investigacion A 40 grupo de investigación al que pertenece el usuario
area_interes A 40 área de interés del usuario
rol A 40 rol del usuario (administrador, usuario, invitado)
estado_cuenta A 40 estado de la cuenta (activada, desactivada)
publicaciones A 100 publicaciones del usuario en revistas para apoyar sus
investigaciones
id_organizacion N 4 id de la Organización a la que pertenece el usuario
id_profesion N 4 ir de la profesión del usuario
cedula N 10 cedula del usuario, con esta se identificará en la
plataforma
*:llave primaria +:llave fóranea
Tabla 6: Metadatos usuarios Fuente: Elaboración propia
89
Experimentos
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Experimentos
Atributos Tipo Longitud Descripción
id_experimento N 50 Id del experimento
descripcion A 40 Descripción del experimento
fecha_creacion F 8 fecha de la creación del experimento
path_1 A 100 path de la configuración del experimento
path_2 A 100 path de los resultados del experimento
nombre N 20 nombre del experimento
respuesta N 1
ambito N 1
estado N 1 el estado del experimento
publico N 1 define si es público con un 1 o si es privado
con un 0
cedula_usuarios N 10 id del usuario que creó el experimento
*:llave primaria +:llave fóranea
Tabla 7: Metadatos experimentos Fuente: Elaboración propia
90
Profesión
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Profesión
Atributos Tipo Longitud Descripción
cod_profesion N 4 Código de la profesión
nombre_profesion A 50 Nombre de la profesión
*:llave primaria +:llave fóranea Tabla 8: Metadatos profesión
Fuente: Elaboración propia
91
Organización
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Organización
Atributos Tipo Longitud Descripción
codigo N 4 Código de la Organización
nombre A 50 Nombre de la Organización
direccion A 50 Dirección de la Organización
email_org A 40 email de la Organización
tipo A 1 Tipo de la Organización, si Local o Foránea al Proyecto
*:llave primaria +:llave fóranea Tabla 9: Metadatos organización
Fuente: Elaboración propia
92
Log
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Log
Atributos Tipo Longitud Descripción
id_log N 50 Id del log
fecha F 8 fecha del acceso o acción
que se insertó en el log
cedula_usuario N 10 cédula del usuario
url A 100 lugar de acceso o acción del usuario
id_organizacion N 4 Código de la Organización
*:llave primaria +:llave fóranea Tabla 10: Metadatos log
Fuente: Elaboración propia
93
Contador Experimento
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Contador_Experimento
Atributos Tipo Longitud Descripción
id N 1 Identificación del contador
constante_local N 2 Indica cuantos experimentos
locales se pueden enviar
local N 2 Indica cuantos experimentos
locales se han enviado
*:llave primaria +:llave fóranea Tabla 11: Metadatos contador experimento
Fuente: Elaboración propia
94
Log Sistema de Encolamiento
AUTORES: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: log_sisencola
Atributos Tipo Longitud Descripción
id N 50 Id del log de
acciones del sistema de encolamiento
fecha F 8 fecha de la acción
numeroproximo N 50 id del experimento
*:llave primaria +:llave fóranea Tabla 12: Metadatos log sistema de encolamiento
Fuente: Elaboración propia
95
4.4.8 Tuplas
FK= LLAVE FORANEA
PK= LLAVE PRIMARIA
Experimentos
Figura 38: Tupla experimento Fuente: Elaboración propia
96
Profesión
AUTOR: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Profesión
cod_profesion nombre_profesion
1 Investigador
2 Profesor
3 Estudiante
Tabla 13: Tupla profesión
Fuente: Elaboración propia
Usuarios
Figura 39: Tupla usuarios Fuente: Elaboración propia
97
Organización
AUTOR: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Organización
codigo tipo nombre direccion email_org
1 Local Universidad Católica de Pereira Cra 21 N° 49-95, Av de las Américas [email protected]
2 Local Universidad Pontificia Bolivariana
Autopista Piedecuesta Kilometro 7 [email protected]
Tabla 14: Tuplas organización Fuente: Elaboración propia
98
Contador Experimento
AUTOR: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: contador_experimentos
local constante_local
1 2
2 2
1 2
2 2
Tabla 15: Tuplas contador experimento Fuente: Elaboración propia
Log
AUTOR: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: Log
id_log fecha cedula_usuario url id_organizacion
1 19/06/2011 1088278633 u2route/registro.php 1
Tabla 16: Tuplas log
Fuente: Elaboración propia
99
Log Sistema de Encolamiento
AUTOR: Mónica Alejandra Naranjo Betancourt Julián Duque Mejía
Daniel Felipe Rios González
SISTEMA: Módulo de Administración de Usuarios y Sistema de Encolamiento
RELACIÓN: log_sisencola
id Fecha numeroproximo
1 19/09/2011 1
2 25/08/2011 2
Tabla 17: Tuplas log sistema de encolamiento Fuente: Elaboración propia
100
4.4.9 Diseño del Plan de Pruebas.
Las pruebas que se realizarán al sistema de acuerdo a lo anteriormente descrito
serán las siguientes:
TEST DE REQUISITOS
PRUEBAS BASADAS EN REQUISITOS
CASO DE PRUEBA: 1 TITULO: Registro de un Nuevo Usuario
PROPÓSITO
Se desea probar que un usuario nuevo que necesite utilizar el sistema web U2ROUTE pueda registrarse.
PREREQUISITO
El nuevo usuario debió notificar por medio de una carta con anterioridad el uso del sistema web. Aceptación para el registro del nuevo usuario.
DATOS DE PRUEBA
Valores que contienen cadenas de caracteres. Límite de caracteres para establecer la contraseña. Validación para el ingreso del correo ya que contiene caracteres especiales.
PASOS
1. Ingresar vía web al portal U2ROUTE. 2. Entrar en la Sección Registrarse. 3. Proporcionar los datos necesarios para el nuevo registro. 4. Clic en registrar para tener acceso como usuario de la plataforma web U2ROUTE.
NOTAS Y PREGUNTAS
Tener en cuenta las ayudas del sistema.
Tabla 18: Caso de Prueba para registrar nuevo usuario Fuente: Elaboración propia
101
PRUEBAS BASADAS EN REQUISITOS
CASO DE PRUEBA: 2 TITULO: Ingreso al Sistema U2ROUTE
PROPÓSITO
Se necesita evaluar que un usuario nuevo registrado con anterioridad pueda ingresar al sistema web U2ROUTE.
PREREQUISITO
El nuevo usuario debe estar registrado y con su cuenta activada para ingresar al sistema web.
DATOS DE PRUEBA
Al momento de digitar la contraseña, esta permite caracteres especiales. La identificación del usuario deben ser solo números.
PASOS
1. Ingresar vía web al portal U2ROUTE. 2. Digitar los datos de usuario y contraseña. 3. Clic en el botón Entrar para tener acceso a los módulos de configuración de la plataforma web U2ROUTE.
NOTAS Y PREGUNTAS
Tener en cuenta las ayudas del sistema.
Tabla 19: Caso de prueba ingreso al sistema web Fuente: Elaboración propia
102
PRUEBAS BASADAS EN REQUISITOS
CASO DE PRUEBA: 3 TITULO: Ingreso al Sistema U2ROUTE
PROPÓSITO
Se necesita evaluar que un usuario nuevo registrado con anterioridad pueda ingresar al sistema web U2ROUTE.
PREREQUISITO
El nuevo usuario debe estar registrado y con su cuenta activada para ingresar al sistema web.
DATOS DE PRUEBA
Al momento de digitar la contraseña, esta permite caracteres especiales. La identificación del usuario deben ser solo números.
PASOS
1. Ingresar vía web al portal U2ROUTE. 2. Digitar los datos de usuario y contraseña. 3. Clic en el boton Entrar para tener acceso a los modulos de configuración de la plataforma web U2ROUTE.
NOTAS Y PREGUNTAS
Tener en cuenta las ayudas del sistema.
Tabla 20: Caso de prueba ingreso al sistema web Fuente: Elaboración propia
103
PRUEBAS BASADAS EN REQUISITOS
CASO DE PRUEBA: 4 TITULO: Configuración Sistema de Encolamiento
PROPÓSITO
Se requiere verificar que el administrador del sistema web U2ROUTE pueda configurar el sistema de encolamiento.
PREREQUISITO
El administrador debe estar registrado en la plataforma web con los permisos activos para realizar cambios en el sistema.
DATOS DE PRUEBA
Valores Numéricos con los que el Sistema de encolamiento tiene la posibilidad de interactuar.
PASOS
1. Ingresar vía web al portal U2ROUTE. 2. Iniciar Sesión como Administrador. 3. Entrar en el enlace Sistema de Encolamiento. 4. Digitar el número de Experimentos locales. 5. Clic en el Botón Guardar.
NOTAS Y PREGUNTAS
La cantidad de Experimentos locales debe ser un número razonable.
Tabla 21: Caso de prueba configuración sistema de encolamiento Fuente: Elaboración propia
104
TEST DE DOCUMENTACIÓN
PRUEBAS DE DOCUMENTACIÓN DE USUARIO
CASO DE PRUEBA: 1 TITULO: Manuales para el Usuario
PROPÓSITO
Se desea conocer cuáles son los manuales de uso que tienen los usuarios para utilizar el sistema web U2ROUTE.
PREREQUISITO El usuario debe ingresar a la página web principal del Sistema U2ROUTE.
DATOS DE PRUEBA No Aplica
PASOS
1. Ingresar vía web al portal U2ROUTE. 2. Entrar en el enlace Documentación. 3. Seleccionar el manual requerido.
NOTAS Y PREGUNTAS
Tener en cuenta las ayudas del sistema. Los manuales se pueden guardar o ver en línea.
Tabla 22: Caso de prueba manuales para el usuario. Fuente: Elaboración propia
105
TEST DE ACEPTACIÓN
PRUEBAS DE ACEPTACIÓN O VALIDACIÓN
CASO DE PRUEBA: 1 TITULO: Revisión Final
PROPÓSITO Conocer si el proyecto como tal del sistema web U2ROUTE es aceptado en su totalidad.
PREREQUISITO El Sistema U2ROUTE debe estar completamente terminado.
DATOS DE PRUEBA Todos aquellos establecidos para el buen funcionamiento de los módulos.
PASOS
1. Presentar la plataforma U2ROUTE funcionando en tiempo real. 2. Entregar un documento que respalde la investigación y el trabajo realizado.
NOTAS Y PREGUNTAS
Recibir nuevas opiniones y si existen correcciones realizarlas.
Tabla 23: Caso de prueba revisión final.
Fuente: Elaboración propia
Finalmente, para tener un sumario de las pruebas realizadas, se presenta una lista de chequeo de pruebas (ver ANEXO 2 – LISTA DE CHEQUEO DE PRUEBAS REALIZADAS)
106
5. PRESENTACIÓN Y ANÁLISIS DE LOS RESULTADOS El resultado final de implementar todos los procesos de ingeniería del software mencionados con anterioridad se tiene un componente software que se ensambla en una aplicación web para la solución del problema planteado. Para lograr esto fue necesario, el saber analizar el problema, diseñar e implementar la mejor propuesta, tener claro la metodología a seguir y los procedimientos que conlleva dicha metodología, por lo cual la unión de estos complementos genera gran cantidad de posibles soluciones, pero se debe elegir la más apta y apropiada para presentar un desarrollo innovador, eficiente y útil para los usuarios que deseen utilizarlo. Este componente software no solo debe interactuar con la aplicación web donde estará almacenada, también debe hacerlo con otros módulos asociados a él para que el funcionamiento total y exitoso del proyecto sea el indicado y lo esperado. Las indicaciones y/o procesos para que el sistema web logre administrar información de usuarios que usen el sistema, configurar experimentos y almacenamiento de datos, son descritos a continuación: La descripción de estos pequeños pero importantes procesos se hace con el fin de que se conozca un poco más a fondo el funcionamiento y la capacidad que tiene el aplicativo web para desarrollar las funciones que se asignaron. En cuanto al Módulo de Administración de usuarios algunos procesos importantes para el buen funcionamiento de dicho módulo están descritos en los siguientes archivos. Estos traen consigo una breve descripción para presentar mejor su funcionamiento: En todos los siguientes archivos se usó PHP y JavaScript en su mayoría; estos
dos para los procesos lógicos, JavaScript para mensajes emergentes para él
usuario y solo Php para la comunicación con la base de datos.
También se usó HTML y CSS para cumplir con los requerimientos no funcionales
para lograr el aspecto actual del módulo de administración de usuarios y no se
note el cambio entre los diferentes módulos para el usuario final.
5.1. ARCHIVOS
ayuda.php:
Contiene enlaces a los diferentes manuales, tanto técnicos como de uso de
los diferentes módulos.
107
correo.php:
Incluye en el sistema las clases de phpmailer que facilitan el envío de
correos a los usuarios:
- class.phpmailer.php
- class.smtp.php
Incluye también los parametros de conexión a la cuenta de la que se envían
los correos y la función de envío del correo:
- Host = "smtp.gmail.com";
- Port = 465;
- Username = '[email protected]';
- Password = „‟;
- $mail->Send();
getorganization.php:
Trae la información de la Organización a la que pertenece el usuario de la
base de datos y la muestra en pantalla.
Datos como:
- Nombre de la Organización
- Dirección
- Correo electrónico
getpro.php:
Trae la información de la Profesión a la que pertenece el usuario de la base
de datos y la muestra en pantalla.
Datos como:
- Nombre de la profesión
index.php
Incluye los siguientes enlaces:
- Registrarse
- Recordar Contraseña
- Documentación
- Repositorio de pruebas
- Integrantes del proyecto
108
Muestra información del Proyecto U2ROUTE en un video.
Contiene también el espacio para el ingreso a U2ROUTE, en este se pide el
usuario y contraseña para que se identifique y permitir el acceso con
privilegios o sin ellos dependiendo el tipo de Usuario.
log.php:
Permite ver el log de acceso y acciones de los usuarios, en este archivo se
verifica que el rol del usuario sea el de Administrador para permitir ver dicha
información.
login.php:
Verifica en la base de datos que la información de acceso ingresada por el
usuario en index.php sea válida, después de esa validación permite o niega
el acceso; si niega el acceso envía un mensaje a index.php para mostrar al
usuario.
panel.php:
Es la primera página a la cual ingresan los Usuarios, en esta se muestra un
menú con diferentes opciones; dependiendo del rol muestra ciertas
opciones o no:
- Para Administrador:
Perfil:
Ingresa a la página profile.php para modificar datos del
perfil del Administrador
Usuarios
Ingresa a la página usuarios.php para modificar datos
del perfil de los Usuarios
Log
Permite ingresar a la página log.php para ver el log de
acceso y acciones de los usuarios
Sistema de Encolamiento
Ingresa a las opciones del Sistema de encolamiento
Salir
Sale del sistema para ser enviado a la página index.php
- Para Usuario:
Perfil:
109
Ingresa a la página profile.php para modificar datos del
perfil del usuario.
Experimento:
Ingresa al módulo de configuración de experimentos
Resultados:
Ingresa al módulo de visualización de resultados
Salir:
Sale del sistema para ser enviado a la página index.php
profile.php:
Permite modificar los siguientes datos del perfil de usuario:
- Nombre
- Apellido
- Grupo de Investigación
- Nombre Organización
- Nombre profesión
- Contraseña
Y solo para el Usuario el ingreso de las publicaciones o modificación de
estas.
recordar_pass.php:
Permite recuperar el password digitando la cedula del usuario, esté es
enviado vía correo electrónico usando las clases de phpmailer y es enviado
al email que el usuario registra.
registro.php:
Permite el registro de un Usuario nuevo, para esto pide los siguientes
datos:
- Nombre
- Apellido
- Cédula (Solo se permiten números, la cédula solamente será
utilizada con fines académicos)
- Grupo de investigación
- E-mail ( ya que sin él no podrá hacer uso de algunas funciones
importantes en el sistema U2ROUTE)
- Contraseña (La contraseña debe tener como mínimo 8 caracteres y
máximo 20 caracteres)
110
- Confirmar contraseña
salir.php:
Permite salir de U2ROUTE y es enviado a la página index.php.
sistema_encolamiento.php:
Permite las siguientes opciones:
Ingreso del contenido de la variable local, para
configurar el algoritmo de prioridad
Ver log de experimentos enviados
Ver log de resultados
Ver log de cambio del contenido de la variable local
usuarios.php:
Permite modificar datos de los usuarios:
- En Perfil:
Nombre:
Apellido:
Grupo de Investigación:
E-mail:
Nombre Organización:
Nombre profesión:
Contraseña:
- En Gestionar Organización:
Solo puede acceder a ella el Usuario con rol de Administrador, en
esta registra la Organización con la información que le llega vía
correo tradicional para el Usuario correspondiente; sino existe la
Organización le permite agregarla.
- En Gestionar Profesión:
Solo puede acceder a ella el Usuario con rol de Administrador, en
esta registra la Profesión con la información que le llega vía
correo tradicional para el Usuario correspondiente; sino existe la
Profesión le permite agregarla.
111
5.2. INTERFAZ DE LA APLICACIÓN
Al ingresar a la página u2route.ucp.edu.co el Usuario se encuentra con las
siguientes imágenes en su pantalla.
Para Administrador:
Figura 40: Página principal Fuente: Elaboración propia
Esta imagen demuestra el primer pantallazo de la plataforma web en donde se
puede iniciar sesión ya sea como administrador o usuario.
Figura 41: Panel administrador
Fuente: Elaboración propia
112
Este panel principal enseña las diferentes opciones que tiene el administrador de
la plataforma para controlar el funcionamiento y uso de esta.
Figura 42: Información administrador Fuente: Elaboración Propia
En la anterior ilustración se puede observar la información relevante del
Administrador, ya que en este caso se ingresó como administrador, es decir
cuando ingrese bien sea otro administrador o un usuario se verificará esta
información al entrar a la opción de Perfil. En esta sección es posible modificar
únicamente los elementos que contengan un signo de Admiración al final de cada
opción, ejemplo el E-Mail es posible Modificar, pero información importante tal
como su Cedula de Ciudadanía no lo puede hacer. Si se realiza algún cambio se
debe guardar en el icono llamado Guardar.
113
Figura 43: Usuarios por administrador Fuente: Elaboración propia
En el enlace usuarios es posible visualizar tres opciones tales como: Perfil del
usuario, Gestionar Organizaciones y Gestionar Profesiones, esto se hace con el
fin generar cambios que el usuario y/o Administrador deseen y sean necesarios.
Figura 44: Gestionar organizaciones Fuente: Elaboración propia
114
Para la sección de Gestionar Organizaciones en las opciones de Nombre,
Dirección, E-Mail se ingresa esta información para crear una nueva organización
al usuario o administrador de la plataforma o si existe alguna organización creada
se puede seleccionar como se muestra en la figura 44.
Figura 45: Gestionar profesiones Fuente: Elaboración propia
En esta parte de la plataforma se ingresa información como el nombre y profesión
para crear una nueva profesión, pero si alguna profesión ya existe como muestra
el ejemplo, Ingeniería de Telecomunicaciones basta con desplegar la pestaña
Profesión, seleccionar la opción que se desea y clic en el botón modificar.
115
Figura 46: Registro de usuarios nuevos Fuente: Elaboración propia
En este parámetro es posible observar el log de un usuario anteriormente creado,
por ejemplo al digitar la Cedula xxxxxxxx el resultado es información general de
dicho usuario como se nota en la figura anterior.
Figura 47: Configuración sistema de encolamiento Fuente: Elaboración propia
116
En esta sección el administrador puede digitar la cantidad de experimentos locales
que se deseen realizar, es decir si digita 4 como en este caso se realizarán 4
experimentos locales por cada 2 foráneas. Además se tienen botones de acción
para revisar los registros de los experimentos enviados, resultados y cambios de
parámetros.
Para Usuario:
Figura 48: Manual de registro Fuente: Elaboración propia
En este enlace se encuentra la información solicitada para el nuevo registro en la
plataforma U2ROUTE, como el nombre, apellido, cédula el grupo de investigación
al cual pertenece, una contraseña, entre otros. Se debe tener muy en cuenta las
advertencias que se encuentran en letra de color azul, ya que si no se cumplen el
registro no será exitoso. Al completar la información solicitada por el sistema web
se debe dar clic en la opción Registrar.
117
Figura 49: Panel principal usuario Fuente: Elaboración propia
En este panel de usuarios es posible visualizar opciones tales como el perfil del
usuario, la configuración de experimentos y el poder revisar los resultados de los
experimentos anteriormente configurados. Todo esto se puede realizar siempre y
cuando se ingresó el usuario y contraseña al crear una cuenta.
Figura 50: Perfil usuario Fuente: Elaboración propia
118
La imagen anterior muestra la información que tiene almacenada el usuario en la
base de datos de la plataforma, si se quiere ver las publicaciones realizadas por
dicho usuario. Esto se puede visualizar en la siguiente figura:
Figura 51: Nueva publicación Fuente: Elaboración propia
El usuario puede crear una nueva publicación y guardarla si lo desea. Sistema de Encolamiento: La construcción final del sistema de encolamiento se basó teniendo en cuenta los requerimientos que fueron dados al inicio del proyecto, este sistema en si es un algoritmo de programación que consta de 224 líneas de código donde se expresan las funciones principales que este debe realizar para que funcione correctamente en el proyecto. Todo este código se encuentra en el archivo llamado servidor_Comunicación_V10.py cuya extensión del archivo es Phyton, con este mismo se logra la comunicación con la Universidad Pontificia Bolivariana. Cabe decir que existieron varias versiones en otros lenguajes tales como PHP, pero debido a nuevos requerimientos se modificó, junto con sus operaciones necesarias para integrarse al proyecto, pero con el fin de brindar la mejor solución. El archivo servidor_Comunicación_V10.py no es nuestra elaboración pero fue hecho con base en nuestro diseño del Algoritmo de prioridad para el Sistema de Encolamiento.
119
Ahora bien, se realizaron una serie de pruebas que permiten verificar las
especificaciones de rendimiento y funcionales que proponen los casos de uso
originales, otras que indican si las interfaces son congruentes con los casos de
uso a los que corresponden, si los mensajes del sistemas son visibles, si se puede
entender los mensajes de falla, entre otros. Se evaluaron también, el
funcionamiento del aplicativo en unidades más pequeñas es decir, si las rutinas y
subprocesos que se crearon arrojaban los resultados esperados.
Igualmente se evaluó la documentación realizada del proyecto, en especial los
manuales de usuario, en el cual la idea era comprobar que existe congruencia
entre el comportamiento del sistema y el manual en sí, que fueran legibles, que
tuviesen buena redacción y que en general fueran comprensibles.
El equipo de desarrollo después de realizar la integración de los respectivos
módulos pertenecientes al proyecto U2ROUTE, verificó que las unidades
trabajasen juntas correctamente mediante casos de uso de pruebas aplicadas a
clases, paquetes de servicio, subsistemas y el sistema del proyecto como tal.
Finalmente se realizó una revisión final por parte de las instituciones relacionadas
con el proyecto para validar el sistema completo, en un ambiente real durante un
periodo extenso.
Todas las pruebas fueron documentadas mediante el desarrollo de casos de pruebas y una lista de chequeo la cual hace un compilado del estado de funcionamiento del sistema, como se puede ver en la tabla anterior, LISTA DE CHEQUEO DE PRUEBAS REALIZADAS.
120
CONCLUSIONES
La unión de diferentes conocimientos posibilita brindar una solución eficaz hacia un problema en particular, generado por una necesidad específica.
Se generó motivación hacia la investigación sobre ciertos temas desconocidos durante el desarrollo de este proyecto, contribuyendo así en la formación como futuros Ingenieros de Sistemas y Telecomunicaciones.
Este tipo de trabajos brinda gran experiencia sobre cómo afrontar, analizar, diseñar y realizar proyectos de investigación.
Se desarrolló la habilidad de crear soluciones a los determinados problemas generados por el proyecto U2ROUTE basados en óptimas decisiones para lograr así una excelente solución de dicho proyecto.
Surgieron nuevos conocimientos sobre el funcionamiento de algunos sistemas ya sean de tipo Software y/o Hardware, contemplando sus ventajas y desventajas.
Es vital el trabajo en equipo, una buena comunicación de los estudiantes y el asesor para el buen fin del proyecto U2 Route.
La solución a este proyecto puede llegar a ser muy útil, ya que en la actualidad, muchos procesos se llevan a cabo por medio del servicio de Internet y el desarrollarlos ha llegado a ser beneficioso para el sector educativo.
Es importante brindar una disponibilidad del 99,5 % de funcionamiento en la plataforma, ya que debe ser un sistema que se encontrará en funcionamiento las 24 horas del día y que puede llegar a presentar fallos eventualmente.
121
RECOMENDACIONES
Los autores del proyecto “DISEÑO E IMPLEMENTACIÓN DE UN MÓDULO DE ADMINISTRACIÓN DE USUARIOS Y DISEÑO DE UN ALGORITMO DE ENCOLAMIENTO PARA INTEGRARSE AL PROYECTO U2-ROUTE” presentan algunas recomendaciones que se pueden tener en cuenta para futuros trabajos de investigación de este tipo:
Tener claro los requerimientos y especificaciones iníciales para no tener problemas durante el desarrollo del proyecto de investigación.
Especificar desde un inicio, los lenguajes de programación que serán usados para la creación de este, para así lograr un buen funcionamiento del proyecto al momento de una unificación si es necesaria.
Manejar adecuadamente el tiempo, de manera que las fechas estipuladas para reuniones sean respetadas, y de esta manera hacer un mejor proceso frente el rodaje del proyecto de investigación.
No modificar las políticas y/o requerimientos aceptados al inicio del proceso de desarrollo investigativo.
Tener sentido de responsabilidad sobre las tareas asignadas a cada integrante de los diferentes grupos del proyecto de investigación, para no ocasionar dificultades en el transcurso del proyecto.
Continuar con estos procesos de formación investigativa, para integrar a los estudiantes y fomentar en sus procesos educativos la importancia de la investigación, con el fin de dar soluciones a problemas futuros.
Es importante tener en cuenta las recomendaciones acerca del funcionamiento de los módulos respecto al direccionamiento IPV6, ya que este sistema desafortunadamente este sistema no lo soporta.
Respecto a la disponibilidad del sistema del proyecto U2ROUTE, es necesario plantear un sistema de respaldo de energía para un posible fallo, ya que este inconveniente podría ocasionar graves problemas al servidor.
La construcción de esta plataforma y su respectiva base de datos fueron construidas sobre el Sistema Operativo Windows, manejando un Gestor de Base de Datos PostgreSQL y Lenguaje de Programación PHP, esto se da a conocer con el fin de posibles modificaciones a futuro, ya sea por parte de otras personas.
122
Se debe tener en cuenta que los parámetros sobre del funcionamiento del proyecto U2ROUTE pueden ser modificados para futuras mejoras de acuerdo a las necesidades que se lleguen a presentar.
123
REFERENCIAS BIBLIOGRÁFICAS Y REFERENCIAS WEB
Anderson, G., & Anderson, P. (2009). Essential JavaFX. En G. Anderson, & P.
Anderson, Essential JavaFX (pág. 343). Santa Calra, California, United States Of
America: Prentice Hall PTR.
Blott, M., Ellithorpe, J., McKeown, N., Vissers, K., & Zeng, H. (2010). FPGA
Research Design Platform Fuels Network Advances. Recuperado el 2 de 2 de
2011, de FPGA Research Design Platform Fuels Network Advances:
http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/Publications
Burgos Viveros, R. (2007). Apuntes sobre sistemas de encolamiento para redes de
computadores. Temuco: Universidad de la Frontera.
Handley, M., Hodson, O., & Kohler, E. (2003). XORP: an open platform for network
research. SIGCOMM Comput.
Kohler, E., Morris, R., Chen, B., Jannotti, J., & Kaashoek, M. F. (2000). The click
modular router. ACM Trans.
Kotler, P., & Armstrong, G. (2006). “El objetivo de la investigación exploratoria es
recopilar la información preliminar que ayudará a definir problemas y a sugerir
hipótesis.”. En P. Kotler, & G. Armstrong, Principles of marketing (11th edition ed.,
pág. 122). Prentice Hall.
Marcos, E. &. (2005). Diseño de Bases de Datos Objeto- Relacionales con UML.
Madrid: Universidad Rey Juan Carlos.
NetFPGA. (2010). NetFPGA - About it (Learn More). Recuperado el 2 de 2 de
2011, de The NetFPGA:
http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/LearnMore
Norris, M., & Rigby, P. (1994). Ingeniería de Software Explicada. En M. Norris, &
P. Rigby, Ingeniería de Software Explicada. Mexico D.F: LIMUSA.
Oracle. (s.f.). jarsigner - JAR Signing and Verification Tool. Recuperado el 24 de 1
de 2011, de Java Platform, Standard Edition (Java SE):
http://download.oracle.com/javase/1.4.2/docs/tooldocs/windows/jarsigner.html
Oracle. (s.f.). Keytool - Key and Certificate Management Tool. Recuperado el 24
de 1 de 2011, de Java SE Technical Documentation - Java Platform, Standard
Edition (Java SE):
http://download.oracle.com/javase/1.4.2/docs/tooldocs/windows/keytool.html
124
PostreSQL. (s.f.). Sobre PostgreSQL. Recuperado el 25 de 1 de 2011, de Sobre
PostgreSQL: http://www.postgresql.org.es/sobre_postgresql
Reyes, J., & Sabino, C. (1999). El proyecto de Investigación Guía para su
elaboración. En F. G. ARIAS ODON, El Proyecto de Investigación: Guía para su
elaboración (pág. 19). Caracas, Venezuela: Episteme.
Rhoton, J. (2000). Programmer’s guide to internet mail: SMTP, POP, and LDAP.
Estados Unidos.
Rivero, C. E. (2004). Bases de datos relacionales: diseño físico (orientado al DB2
para z. Madrid: Universidad Pontifica de Comillas.
Sangjin Han, K. J. (2010). PacketShader: a GPU-accelerated software router. In
Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM (SIGCOMM
'10). New York NY, USA.
Sommerville, I. (2005). Ingenieria del Software. En I. Sommerville, Ingenieria del
Software (7ºEdicion ed., pág. 687). Pearson Educacion.
Wiseman, C., Turner, J., DeHart, J., Parwatikar, J., & Wong, K. (2009). NetFPGAs
in the Open Network Lab (ONL). En W. University, NetFPGA Developers
Workshop. Stanford,CA.
125
ANEXOS
126
ANEXO 1 - FORMATO DE REQUERIMIENTOS
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _001____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
No hay información de los usuarios que requieren el uso del Sistema Web U2Route; sin esta información no se puede dar acceso al Sistema, no se puede conocer quienes lo usan, no se le puede permitir al Usuario ingresar a hacer pruebas ya que no se podrá identificar a quien pertenece la prueba realizada en el laboratorio remoto.
Requerimientos
Nombre del Requerimiento Registro de Usuarios
Código del Requerimiento RF 1
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional
☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En construcción ☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear un módulo de registro de usuarios en el que se pida la información de interés (Nombre, Apellidos, Documento de Identificación, Contraseña, Grupo de Investigación, Correo) y este a su muestre un mensaje de registro correcto. (Toda esta información debe guardarse en una base de datos)
Complemento de Requerimientos
Interfaces de Usuario: Se requiere crear un enlace que envíe al usuario a una página de registro.
Requerimientos de Hardware: Se requiere almacenamiento en disco para que la persistencia de la información.
Requerimientos de Software: Integrar a una base de datos para la persistencia de la información y administración de esta.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
127
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _002____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
Los usuarios no pueden ingresar al Sistema Web U2Route porque no existe una función en este que les permita hacerlo
Requerimientos
Nombre del Requerimiento Ingreso al Sistema Web U2Route
Código del Requerimiento RF 2
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Permitir al usuario ingresar al Sistema Web U2Route con credenciales de acceso (Usuario y password)
Complemento de Requerimientos
Interfaces de Usuario: Se requiere que este módulo de ingreso al Sistema Web se encuentre en la página principal, en la parte superior izquierda, después del logo (donde comienza el contenido de la web)
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
128
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _003____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
Los usuarios no pueden ingresar al Sistema Web por olvido de la contraseña
Requerimientos
Nombre del Requerimiento Recuperar Contraseña
Código del Requerimiento RF 3
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Permitir que el usuario recupere su contraseña por medio del correo registrado
Complemento de Requerimientos
Interfaces de Usuario: Se requiere crear un enlace que envíe al usuario a una página de recuperación de contraseña, este enlace preferiblemente esté debajo de las casillas para digitar las credenciales para acceso al Sistema Web U2Route.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local. También con un sistema de envío de correo automático para que el proceso sea transparente al usuario y ágil.
129
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _004____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
No hay forma de que una persona sin conocimiento de bases de datos administre la información en ella.
Requerimientos
Nombre del Requerimiento Usuario con permisos especiales (Administrador del Sistema Web U2Route)
Código del Requerimiento RF 4
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear un usuario con permisos especiales para administrar el Sistema Web U2Route.
Complemento de Requerimientos
Interfaces de Usuario: El administrador ingresará con sus credenciales; al ingresar se encontrará con unas funciones especiales que le permitirá administrar debidamente el Sistema Web U2Route.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
130
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _005____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
El usuario se registra e inmediatamente puede ingresar al sistema creando problemas ya que cualquier persona podría usar el Sistema Web U2Route; el Sistema Web es exclusivo para investigadores.
Requerimientos
Nombre del Requerimiento Activación de cuenta
Código del Requerimiento RF 5
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Validar si la información del usuario es real para luego activarle la cuenta, obligándolo a demostrar que su información es válida.
Complemento de Requerimientos
Interfaces de Usuario: El administrador ingresará con sus credenciales; al ingresar se encontrará con unas funciones especiales que le permitirá administrar debidamente el Sistema Web U2Route.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local. También con un sistema de envío de correo automático para que el proceso sea transparente al usuario y ágil. Por medio de correo tradicional el usuario enviará su información de registro con una petición formal para el uso del Sistema Web U2Route
131
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _006____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
Los investigadores no pueden ver el repositorio de pruebas público.
Requerimientos
Nombre del Requerimiento Ver repositorio de pruebas público
Código del Requerimiento RF 6
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema
☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Permitir, por medio de un perfil de usuario público, visualizar el repositorio de pruebas público.
Complemento de Requerimientos
Interfaces de Usuario: Este módulo de repositorio de pruebas es desarrollado por otro grupo de trabajo; solo es necesario crear un enlace hacia el con un perfil de usuario público.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local. Requiere comunicarse con el módulo de repositorio de pruebas para mostrarlo pero de forma limitada ya que solo es necesario ver las pruebas públicas.
132
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _007____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
Los usuarios se pierden en el Sistema en algunas secciones ya que no hay indicaciones.
Requerimientos
Nombre del Requerimiento Documentación para el Usuario
Código del Requerimiento RF 7
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio
☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear un fácil acceso a los manuales de usuario para que estos sean fácilmente adquiridos por los usuarios.
Complemento de Requerimientos
Interfaces de Usuario: Crear una página para listar los manuales de usuario. Crear un enlace a la página donde se encuentran los manuales, este enlace deberá encontrarse en todas las páginas y también en la página principal.
Requerimientos de Hardware:
Requerimientos de Software: Los manuales se deben mostrar fácilmente en un formato reconocido, se recomienda pdf.
Requerimientos de comunicación: Se requiere consultar en disco al momento del usuario requerir los manuales.
133
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _008____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
No hay forma de lograr una exclusividad según la Organización a la que el usuario pertenezca, este es un parámetro importante para el buen funcionamiento del Sistema de encolamiento. El administrador no tiene la opción de administrar la información del usuario, al momento de confrontar la información de la carta enviada por el usuario no se puede hacer nada ya que esta opción no existe.
Requerimientos
Nombre del Requerimiento Cambio de información por parte del Administrador y del Usuario
Código del Requerimiento RF 8
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En construcción ☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear una sección para modificar la información registrada por el usuario, incluyendo la modificación de la Organización a la que el usuario pertenece. Se debe tener en cuenta que el Administrador puede cambiar toda la información (incluyendo la propia) y el usuario solo puede cambiar el correo y la contraseña.
Complemento de Requerimientos
Interfaces de Usuario: Crear una página para administrar la información del Usuario enlazada a una opción en un menú llamada perfil en el caso del Usuario y del Administrador .Adicional a esto una página enlazada a una opción en el menú llamada Usuarios donde el Administrador pueda elegir a que usuario quiere modificar incluyendo la información de la Organización y su profesión.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
134
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _009____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
No existe una integración con los módulos de Experimentos y Resultados, el usuario no puede ingresar identificado a estos módulos y tampoco puede ingresar fácilmente.
Requerimientos
Nombre del Requerimiento Cambio de información por parte del Administrador y del Usuario
Código del Requerimiento RF 9
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No funcional ☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear dos opciones en el menú, una para el Módulo de Experimentos y otra para el de Resultados; estas deben llevar la información del usuario necesaria para identificarlo en dichos módulos.
Complemento de Requerimientos
Interfaces de Usuario: En un menú se deben agregar las opciones para que el usuario ingrese solamente dando clic al Módulo de Experimento y al de Resultados.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local. Este deberá comunicarse con los Módulos (Experimentos y Resultado) creados por otros grupos de desarrollo.
135
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _010____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
No se sabe a dónde accede el usuario y que acciones hace en el Sistema Web U2Route complicando el control del usuario o la detección de errores.
Requerimientos
Nombre del Requerimiento Log de Usuario
Código del Requerimiento RF 10
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear un log de acceso y acciones para el usuario y este sea visto desde el Administrador.
Complemento de Requerimientos
Interfaces de Usuario: En un menú en la parte de Administrador crear una opción para acceder a una página donde se encuentra el log de los usuarios. Crear una página para elegir a un usuario al que se le desee ver el log para mostrar de forma ordenada.
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
136
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _011____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
El Cliente decidió darle prioridad a las Organizaciones involucradas en el Proyecto U2Route pero no hay un sistema en este que le permita dar prioridad a algunos usuarios al momento de realizar experimentos en el laboratorio remoto.
Requerimientos
Nombre del Requerimiento Sistema de Encolamiento
Código del Requerimiento RF 11
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear un algoritmo de prioridad para el envío de pruebas, este debe enviar inicialmente 2 pruebas por cada 1 prueba enviada de Organizaciones que no pertenezcan al desarrollo de U2Route. Se requiere que tome de la base de datos estos parámetros ya que se desea sean modificables.
Complemento de Requerimientos
Interfaces de Usuario: Esto es un proceso transparente para el usuario y el administrador
Requerimientos de Hardware:
Requerimientos de Software: Se requiere adquirir información de la base de datos para la prioridad de las Organizaciones.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
137
(Universidad Católica de Pereira – U2ROUTE)
Fecha: 06 / 09 / 2011 / CODIGO DEL FORMATO: _012____________
Medio por el cual fue recibido ☒Oral ☐Teléfono ☐Medio Electrónico ☐Otro:________________
Planteamiento Problema
Al Usuario le gustaría que el Sistema de encolamiento se pudiese administrar, no se puede cambiar los parámetros de envío de pruebas y tampoco se sabe si está funcionando.
Requerimientos
Nombre del Requerimiento Administración del Sistema de Encolamiento
Código del Requerimiento RF 12
Prioridad del Requerimiento según el Cliente ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Prioridad Requerimiento Equipo Desarrollador ☒Alta/Esencial ☐Media/Deseado ☐Baja/ Opcional
Tipo de Requerimiento
☒Funcional ☐No
funcional
☒Proceso ☐Producto ☐Negocio ☐Entorno ☐Usuario ☐Sistema ☐Interfaz ☐Interface
Estado ☒Recibido ☐En Estudio ☐Viable ☐No Viable ☐En
construcción
☐En pruebas ☐Implementado
Tiempo Estimado
Ponderación Requerimiento (%) %
Descripción del Requerimiento Crear la administración del sistema de Encolamiento, log de uso (Envío de prueba y pruebas recibidas), cambio de parámetros de pruebas Locales.
Complemento de Requerimientos
Interfaces de Usuario: En un menú en la parte de Administrador crear una opción para acceder a una página donde se encuentre la administración del Sistema de Encolamiento. Crear una página para elegir el parámetro local del sistema de encolamiento y mostrar su respectivo log de cambios a este. Mostrar los logs creados por el Sistema de Encolamiento
Requerimientos de Hardware:
Requerimientos de Software: Se requiere confrontar la información con la que se encuentra en la base de datos para validarla.
Requerimientos de comunicación: Este deberá comunicarse con una base de datos en un servidor local.
138
ANEXO 2 - LISTA DE CHEQUEO DE PRUEBAS REALIZADAS
Secuencia Actividad Chequeo / Autor
Chequeo / Verificador
Observaciones
Descripción Preliminar
1 ¿Tiene la capacidad de Registrar y Administrar Usuarios Nuevos? SI SI
2 ¿Permite iniciar sesión con usuario y contraseña? SI SI
3 ¿El sistema permite recuperar la contraseña? SI SI
4 ¿Existe un Administrador del Sistema Web U2Route? SI SI
5 ¿Permite el Sistema activar nuevas cuentas? SI SI
6 ¿Es Posible Visualizar el registro de pruebas públicas? SI SI
7 ¿Hay Documentación para el usuario? SI SI
8 ¿Posibilidad de Modificar la información por parte del Administrador y el Usuario? SI SI
9 ¿Registro de usuarios existe? SI SI
10 ¿El Sistema de Encolamiento Funciona? SI SI
11 ¿Existe la posibilidad de administrar el Sistema de Encolamiento? SI SI
12 ¿Aceptación total del Producto? SI SI Aceptado.
Prototipo
13 ¿El prototipo permite visualización evitando uso de scroll? SI SI
14 ¿El prototipo refleja el estilo de presentación definido (alineación, color? SI SI
Precondiciones – Postcondiciones
15 ¿Están definidas las precondiciones y pos condiciones del caso de uso? SI SI
Elementos de Interfaz
16 ¿Las descripciones de los elementos están completamente definidas? SI SI
17 ¿Los elementos se describen de acuerdo al orden indicado en el prototipo? SI SI
Flujo de Eventos
18 ¿El flujo de eventos determina todas las posibles interacciones entre el usuario y el sistema?
SI SI
19 ¿El flujo de eventos tiene asociado elementos de negocio donde es requerido? SI SI
Requerimientos
20 ¿Se han asociado los requerimientos que aplican al caso de uso y que describen en detalle las restricciones y o validaciones indicadas en los elementos de interfaz'
SI SI
Uso de casos de prueba para esto
Realizo: Alejandra Naranjo, Julián Duque, Daniel Felipe Ríos.
Aprobó: Jhonattan Córdoba