proyecto entorno educativo web
Post on 17-Dec-2015
218 Views
Preview:
DESCRIPTION
TRANSCRIPT
Ao de la Diversificacin Productiva y del Fortalecimiento de la Educacin
Carrera Profesional de Computacin e Informtica
Proyecto de Metodologa para la Migracin de Sistemas Educativo Distribuido a un Entorno Web
TRABAJO TERICO PRCTICO Presentado por:
Carlos Rojas Avellaneda
Huancayo Per
2015
A: Mis padres por su cario y apoyo incondicional.
NDICE GENERAL
Portada..i Dedicatoria...iii ndiceiv Introduccin..v
Captulo I
DESCRIPCIN Y CARACTERSTICAS DEL PROBLEMA
1.1.Caractersticas y consecuencias del problema .....................................................2
1.1.1.Reconstruccin................................................................................................3
1.1.2.Encapsulamiento.............................................................................................3
1.1.3.Migracin .........................................................................................................3
1.2.Estrategias de migracin ........................................................................................4
1.2.1.Habilitacin gradual.........................................................................................4
1.2.2.Habilitacin sbita ...........................................................................................5
1.3.Los pilares de todo el proceso de migracin .........................................................5
1.4.Interrogantes para migrar a la Web .......................................................................6
1.4.1.Metas ...............................................................................................................7
1.4.2.Diseo Web .....................................................................................................7
1.4.3.Recursos .........................................................................................................7
1.4.4.Tcnico ............................................................................................................7
1.4.5.Perspectivas de negocio .................................................................................7
1.5.Problemas con la arquitectura Cliente/Servidor ....................................................8
1.6.Beneficios del proceso de migracin ...................................................................10
Captulo II
METODOLOGA PARA LA MIGRACIN DEL SISTEMA
2.1. Metodologa propuesta de anlisis lgico y fsico del sistema a migrar .............12
2.1.1.Reconstruccin de la especificacin de requerimientos ..............................12
2.1.1.1.Estudio Preliminar ..................................................................................13
2.1.1.2.Reconstruccin. .....................................................................................13
2.1.2. Descripcin de la dimensin funcional. ........................................................13
2.1.2.1.Elaboracin del diagrama de contexto ..................................................13
2.1.2.2.Anlisis de comportamiento del sistema ...............................................14
2.1.2.3.Construccin de diagramas de flujo ......................................................14
2.1.2.4.Realizacin del modelo de casos de uso ..............................................14
2.1.3.Descripcin de la dimensin esttica del sistema anterior ..........................14
2.1.3.1.Reconstruccin del modelo conceptual.................................................15
2.1.4.Descripcin de la interfaz de usuario............................................................15
2.1.4.1.Anlisis del modelo de interfaz de usuario ............................................15
2.1.4.2.Construccin del modelo del sistema ....................................................15
2.1.5.Descripcin de la arquitectura fsica y del software de base .......................16
2.1.5.1.Arquitectura fsica ..................................................................................16
2.1.5.2.Arquitectura del Software de Base y diagrama de componentes.........17
2.1.5.3.Anlisis de la limitaciones del modelo anterior .....................................17
2.2. Metodologa propuesta de anlisis lgico y fsico del sistema migrado..............18
2.2.1. Adecuacin de la especificacin de requerimientos ....................................18
2.2.1.1.Estudio preliminar ..................................................................................18
2.2.2.Adecuacin de la descripcin funcional .......................................................18
2.2.2.1.Revisin del modelo funcional ...............................................................18
2.2.2.2.Realizacin del modelo de casos de uso de la aplicacin Web ...........19
2.2.3. Adecuacin de la descripcin de la dimensin esttica ...............................19
2.2.3.1.Revisin del modelo conceptual ............................................................19
2.2.4.Descripcin de la interfaz del usuario en la aplicacin Web ........................20
2.2.4.1.Anlisis del modelo de interfaz de usuario ............................................20
2.2.5. Revisin de la arquitectura fsica y del software de base ............................20
2.2.5.1.Arquitectura fsica ..................................................................................20
2.2.5.2.Arquitectura del Software de Base y diagrama de componentes .........21
Captulo III
ANLISIS DEL SISTEMA A MIGRAR
3.1. Aplicacin de la Metodologa para el anlisis del Sistema a Migrar ...................23
3.1.1.Estudio preliminar .........................................................................................23
3.1.1.1.Servicios prestados por el Sistema .......................................................23
3.1.1.2.Relacin con otros Sistemas .................................................................23
3.1.1.3.Alcance del Sistema ..............................................................................24
3.1.2.Caractersticas generales y reglas de administracin..................................24
3.1.2.1.Perfiles ...................................................................................................24
3.1.2.2.Auditoria. ................................................................................................25
3.1.2.3.Programacin .........................................................................................25
3.1.2.4.Base de Datos........................................................................................25
3.1.2.5.Listado de procesos ...............................................................................25
3.1.2.6.Reglas de administracin ......................................................................26
3.1.3. Descripcin de la dimensin funcional .........................................................26
3.1.3.1.Elaboracin del diagrama de contexto ..................................................26
3.1.3.2.Anlisis de comportamiento del sistema. ..............................................27
3.1.3.3.Construccin del diagrama de flujo de datos - DFD .............................28
3.1.3.4.Realizacin del modelo de casos de uso de la aplicacin anterior ......30
3.1.4. Descripcin del modelo conceptual del sistema administrativo ...................30
3.1.5.Descripcin de la interfaz del usuario...........................................................32
3.1.5.1.Anlisis del Modelo de Interfaz del Usuario ..........................................32
3.1.6. Descripcin de la arquitectura fsica y del software de base .......................38
3.1.6.1.Arquitectura fsica ..................................................................................38
3.1.7.Anlisis de las limitaciones del modelo anterior implementado ...................38
Captulo IV
RESULTADOS DE LA MIGRACIN DE UNA APLICACIN DISTRIBUIDA A UN
ENTORNO WEB
4.1. Aplicacin de la metodologa para el anlisis del sistema migrado ....................40
4.1.1.Estudio preliminar .........................................................................................40
4.1.1.1.Servicios prestados por el sistema ........................................................40
4.1.1.2.Relacin con otros sistemas ..................................................................41
4.1.1.3.Alcance del Sistema ..............................................................................41
4.1.1.4.Caractersticas tecnolgicas ..................................................................42
4.1.1.5.Reutilizacin de requisitos en el proceso de migracin a la Web.........43
4.1.1.6.Previsiones para superar las limitaciones comprobadas en el sistema
original.44
4.1.2.Adecuacin de la descripcin funcional ................................................46
4.1.2.1.Revisin del modelo funcional ...............................................................46
4.1.2.2.Realizacin del modelo de casos de uso de la aplicacin Web ...........47
4.1.3. Adecuacin de la descripcin de la dimensin esttica ...............................47
4.1.4.Descripcin de la interfaz de usuario en la aplicacin web .........................50
4.1.4.1.Anlisis del modelo de interfaz de usuario de la aplicacin Web .........50
4.1.4.2.Construccin del modelo de la aplicacin web .....................................51
4.1.5.Revisin de la arquitectura y del software de base ......................................52
4.1.5.1.Arquitectura ............................................................................................52
4.1.5.2.Diagrama de componentes de la aplicacin web..................................53
Captulo V
EVALUACIN
5.1.Plan de pruebas....................................................................................................55
5.2.Pruebas de funcionalidad .....................................................................................55
5.3.Pruebas a detalle..................................................................................................56
5.4.Pruebas de compatibilidad ...................................................................................64
5.5.Pruebas de tiempo de respuesta .........................................................................66
5.5.1.Pruebas a detalle ..........................................................................................66
Conclusiones.....70
Sugerencias...72
Bibliografa.....73
Anexos74
INTRODUCCIN
El trabajo de investigacin que presentamos se centra en fundar un metodologa que permita la migracin de sistemas distribuidos a un entorno web, que al ser convertidos mantenga exactamente la misma funcionalidad que los originales, sin modificar los procedimientos de la organizacin que los utiliza, pero sin quedar fuera la posibilidad de incluir nuevas caracterstica o mejoras que permitan evolucionar al sistema.
La investigacin de este proyecto se realiz por el inters de obtener un sistema de informacin que se relacione con las nuevas tecnologas de la informacin y del internet, compatible a la nueva mentalidad empresarial que intenta ofrecer mejores servicios a sus clientes.
Para ello se formula una metodologa para el anlisis lgico y fsico de las aplicaciones distribuidas a migrar a entornos Web, y se pone en prctica aplicndola a un caso de estudio. Este caso corresponde a un sistema distribuido desarrollado mediante el uso de una metodologa de anlisis y diseo estructurado y la aplicacin migrada a la Web fue desarrollada mediante el uso de alguna metodologa basada en UML. Y para la comprobacin de resultados se aplica conocimientos sobre testing de regresin, testing de caja negra y testing de interfaces grficas con el usuario.
OBJETIVOS
Objetivo General
Crear una metodologa para migrar un Sistema distribuido a un entorno Web que preservara las principales propiedades de la aplicacin original, tales como son su especificacin, funcionalidad y propiedades de la interfaz grfica con el usuario.
Construir modelos para abstraer propiedades en comn de modelos de aplicaciones Web y de modelos de aplicaciones tradicionales, los que sirven de base para mapear casos de uso. Formular una metodologa de anlisis para la migracin de aplicaciones distribuidas a entornos Web, basada en un enfoque de testing con reutilizacin de casos de prueba. Aplicar la metodologa propuesta tomando como caso de estudio el Sistema de Gestin Acadmica de una institucin universitaria a efectos de comprobar su desempeo.
Estructura de la Tesis
El Captulo1 presenta el problema de la migracin de sistemas a la Web y el modo de gestionar su evolucin. Asimismo, plantea algunos de los interrogantes que se formulan previos a la realizacin de una migracin de una aplicacin cliente/servidor a Web, las posibles soluciones a los mismos y una exposicin de los principales beneficios que se obtienen con este proceso.
El Captulo 2 presenta en primer trmino un metodologa para el conocimiento del nuevo sistema a migrar, luego, se presenta una metodologa para el conocimiento del nuevo sistema que ya ha sido migrado, y para este ltimo se pone el foco en la arquitectura cliente servidor, en la tecnologa Web
En el Captulo 3 se realiza una descripcin del sistema actual de la Institucin Nuestra Virgen del Rosario que sirve como punto de partida para comprender los requerimientos del sistema.Y a fin de continuar con el uso de la metodologa estructurada.
El Captulo 4 se aplica la metodologa de migracin tomando como caso de estudio el sistema de Autogestin de Alumnos de la Institucin Nuestra Virgen del Rosario. A lo largo de este captulo, se da un estudio comparativo y se aplican las metodologas utilizadas para el desarrollo del sistema antiguo y del actual. En este desarrollo, se centra el foco de atencin en la reutilizacin de requisitos en el proceso de migracin a la Web.
El Captulo 5 plantea un enfoque funcional del testing de migracin al caso de estudio. Permitiendo visualizar convenientemente las diferencias existentes entre los mismos, para lo cual se presenta una clasificacin de las condiciones que les dan origen y la posibilidad de su reutilizacin. Asimismo se realiza un estudio comparativo de la interfaz de ambos sistemas.
Finalmente un agradecimiento especial al Ing. Jess Alberto Zea Salas, por haber aceptado la direccin de este proyecto y por habernos brindado su ayuda y aliento durante todo su desarrollo.
1
Captulo I
DESCRIPCIN Y CARACTERSTICAS DEL PROBLEMA
Resulta importante precisar el alcance de la palabra migracin. Una de las acepciones del trmino hace referencia a la accin de convertir los programas de un lenguaje a otro, habitualmente desde lenguajes como el Cobol hacia el Java, lo que en este caso implica cambiar el paradigma de construccin de las aplicaciones desde un modelo procedimental hacia un modelo orientado a objetos.
En una interpretacin ms amplia, se hace referencia a la migracin de un sistema de computacin cuando se lo traslada de una plataforma a otra, lo que puede involucrar cambios de arquitectura y/o de tecnologa, y normalmente lleva implcita la necesidad de reescribir los programas en un lenguaje diferente.
Si solo se considera la conversin de los lenguajes de los programas, en el mercado existen traductores de cdigo que tienen la finalidad de contribuir a facilitar esta tarea. Sin embargo, estos cumplen una funcin esencialmente sintctica, normalmente pobre desde el punto de vista semntico, y sus resultados se alejan demasiado del objetivo deseado. La traduccin del cdigo sin cambio en el paradigma conduce a programas monolticos, ineficientes y difcilmente mantenibles. Por el contrario, si se considera el concepto de migracin en su interpretacin ms amplia, el problema adquiere la dimensin de un proyecto de ingeniera de software y debe ser tratado en consecuencia, para lo cual se presentan diferentes alternativas.
2
El concepto de migracin de un sistema no est taxativamente definido y en muchos casos se lo confunde con el de reingeniera, por lo que, para comenzar, es necesario aclarar el alcance de ambos trminos. Se entiende como reingeniera a la casi completa reconstitucin y reimplementacin de un sistema, sin que haya necesariamente un cambio de plataforma o ambiente de operacin. Por el contrario, la migracin evita el redesarrollo completo del sistema al usar todos los antecedentes disponibles (requerimientos, diseos, etc.) y siempre implica un cambio en el ambiente de operacin. Por lo tanto, al hablarse de migracin se est haciendo referencia a la necesidad de trasladar un sistema a una nueva plataforma manteniendo sus funcionalidades y provocando mnimo impacto en su operacin.
Para comprender la importancia de esta metodologa se reitera la situacin que enfrentan muchas organizaciones en la actualidad: la necesidad de trasladar aplicaciones informticas crticas para el negocio, y que necesitan ser adaptadas para su funcionamiento a los canales que ofrecen las nuevas tecnologas, tales como Internet.
1.1. Caractersticas y consecuencias del problema
La evolucin de la tecnologa computacional con el paso del tiempo ha conducido a que muchos sistemas informticos incorporen un conjunto de caractersticas no deseadas que son las siguientes:
Operan sobre hardware obsoleto, que es lento y costoso de mantener.
El mantenimiento del software tambin es costoso y lento, principalmente por la falta de documentacin y de conocimiento de la estructura interna del sistema.
Los esfuerzos de integracin se ven muy limitados por la ausencia de interfases.
En respuesta a estos problemas se han propuesto diversas soluciones que pueden ser agrupadas en las siguientes tres categoras:
3
1.1.1. Reconstruccin
La reconstruccin implica reescribir las aplicaciones existentes, y dependiendo de la documentacin y conocimiento disponible sobre el sistema actual, puede tratarse desde una reingeniera hasta el rediseo de un sistema completamente nuevo. Esto ltimo ya fue referido como abandono del sistema para su sustitucin por otro nuevo.
1.1.2. Encapsulamiento
Con encapsulamiento se hace referencia al desarrollo de una envoltura de software (wrapper) sobre la aplicacin existente, con el fin de dotarlo de interfases con componentes perifricos que permitan sacarlo de su aislamiento.
1.1.3. Migracin
La migracin de un sistema de informacin tiene por finalidad su traslado a un nuevo ambiente operativo, conservando su funcionalidad y datos originales. En todos los casos se persigue posibilitar el mantenimiento y posterior adecuacin a nuevos requerimientos.
Dado un problema concreto de un sistema que rena las cualidades, muchas veces tipificado como sistema heredado, no es siempre posible decidir cul es la solucin ms conveniente y en muchos casos lo apropiado es una combinacin de ellas. Sin embargo, es muy poco probable que la completa substitucin del sistema sea una verdadera opcin y la solucin prctica del problema suele hallarse entre el encapsulamiento y la migracin. La primera es muchas veces reconocida como una solucin de compromiso o de corto plazo y se reconoce que la ltima, no siempre posible, es la que verdaderamente representa solidez y previsibilidad futura.
En efecto, en situaciones donde por diferentes motivos se descartan las opciones de reconstruccin y de encapsulamiento, la migracin del sistema a un ambiente abierto se convierte en la mejor alternativa. Si bien esta es la
4
opcin ms compleja, las ventajas que se obtienen a largo plazo justifican ampliamente el esfuerzo que ser requerido.
Aqu debe reconocerse que un trabajo de migracin es normalmente un proyecto de ingeniera de sistemas, que por su importancia merece el calificativo de crtico. Esto es as tanto por la relevancia de los entornos migrados (datos y aplicaciones), que debern ofrecer finalmente la misma eficiencia y operatividad que ofrecan en el entorno anterior, como as tambin por la necesidad de hacer mnimo el impacto en todos los niveles de la organizacin. Se hace referencia aqu al objetivo de enfrentar un cambio de cultura tecnolgica, para el que habr que prever recursos tcnicos y humanos, y que deber ser acompaado del necesario entrenamiento del personal y usuarios.
Adems, durante el proceso de cambio del sistema ser muy importante prever cul ser la gestin de su evolucin posterior; con el fin de evitar que la situacin presente vuelva a repetirse o al menos resulte menos traumtica. La gestin de la evolucin debe consistir en el ofrecimiento de una respuesta rpida, preparada y eficiente a los cambios que se produzcan en el entorno, ya sean de ndole tecnolgica o de gestin del propio negocio.
1.2. Estrategias de migracin
Las estrategias de migracin reconocen los dos enfoques siguientes:
1.2.1. Habilitacin gradual
La nueva aplicacin es construida gradualmente en la plataforma de destino, hacindose cargo en forma progresiva de las funcionalidades de la aplicacin original, por lo que en este proceso ambas aplicaciones estn integradas en un nico sistema con una transferencia gradual de responsabilidades de una a otra. Con este enfoque la informacin est duplicada y es necesario un importante esfuerzo de coordinacin para asegurar la integridad y consistencia de los datos.
5
1.2.2. Habilitacin sbita
La aplicacin original mantiene todas sus prestaciones mientras la aplicacin en la nueva plataforma es construida, implementada y probada. Las bases de datos de esta ltima son progresivamente actualizadas hasta el momento en que se decide la transferencia del control, momento en que la aplicacin original queda desafectada y sus bases de datos quedan como referencia nicamente para consulta.
Se debe tener en cuenta que antes del desarrollo del nuevo sistema, es imprescindible tener una comprensin intensiva del sistema a ser migrado.
En cualquier sistema a ser migrado, algunas caractersticas son comunes con todo proyecto de ingeniera de software, tales como metodologa de desarrollo, testing y seleccin del modelo de bases de datos. Otras, son especficas de la migracin, por lo que se puede clasificarlas en dos grandes categoras: aquellas que conciernen al sistema a migrar, y, las especficas del sistema migrado, para lo cual es necesario entender las caractersticas intrnsecas de los datos, las interfases y las aplicaciones involucradas, en cualquier proceso de migracin.
Consecuentemente, antes de tomar cualquier decisin sobre la estrategia de migracin, se debe realizar un estudio intensivo a los efectos de cuantificar los riesgos y beneficios, con el fin de justificar acabadamente la migracin a un nuevo sistema, segn lo proponen.
1.3. Los pilares de todo el proceso de migracin
Una migracin debe apoyarse en tres pilares bsicos, a saber: 1) una metodologa, 2) un conjunto de herramientas y 3) tcnicas de pruebas y personalizacin.
La metodologa garantiza, en primer lugar, un procedimiento sistemtico que asegura que el trabajo realizado sea controlable y sus resultados predecibles.
6
En segundo lugar, que se dispone de un repositorio con toda la informacin necesaria para abordar la migracin: cadenas de programas, programas fuente, estructura de bases de datos, libreras de funciones, etc. En tercer lugar, contempla la obtencin del modelo de negocio a migrar, a partir de la informacin contenida en el repositorio, y considera adems la realizacin de los planes de prueba de las aplicaciones migradas. Por ltimo, define las reglas de generacin del cdigo migrado, conforme a los estndares establecidos, las libreras de funciones usadas y cualquier otra consideracin de inters.
Las herramientas de migracin permiten obtener un modelo del negocio a migrar, que lo hace independiente de los lenguajes de las aplicaciones, con lo cual el modelo obtenido resultar vlido en caso de ser necesarias futuras migraciones a otras tecnologas. Estas herramientas deben permitir, tambin, la incorporacin de las reglas bsicas del negocio a los efectos de obtener aplicaciones optimizadas para su funcionamiento en el entorno informtico existente en una empresa.
Las tcnicas de pruebas y personalizacin incorporan las reglas de generacin introducidas por la metodologa a los fines de obtener aplicaciones funcional y operativamente fiables y las optimizan para su funcionamiento en el entorno informtico existente en la empresa.
La utilizacin de estos tres pilares permite asegurar el xito del proyecto, manteniendo los plazos y costos de realizacin dentro de las previsiones.
1.4. Interrogantes para migrar a la Web
A continuacin se presentan algunos de los interrogantes que se debe plantear una organizacin antes de realizar una migracin de una aplicacin Cliente/Servidor a la Web, agrupados segn los distintos aspectos con los que stos se relacionan.
7
1.4.1. Metas
Cul es el objetivo y su motivacin?, es una necesidad o simplemente un deseo?
Qu debe realizar el sitio Web?
Cmo interactuar el sitio Web con las aplicaciones existentes?, a travs de procesos, de datos u otro tipo de integracin? Cul ser el futuro de las aplicaciones existentes?
1.4.2. Diseo Web
Cul es la apariencia prevista para el sitio?
Tienen los elementos de diseo grfico un gran impacto sobre el negocio? Se requiere contenido esttico o dinmico?
Quines pueden acceder al sitio?
Cules son los requerimientos de seguridad?
Cmo es el flujo de las pginas Web?
Se harn ingresos de datos o slo reportes?
1.4.3. Recursos
Cul es el presupuesto necesario?
Con qu soporte organizacional se debe contar?
Cul es el nivel de conocimientos que deben poseer los programadores?, requieren entrenamiento?
Es el entrenamiento un objetivo organizacional?
1.4.4. Tcnico
Cul es el sistema operativo para el servidor?
Qu servidor de aplicaciones se debe usar?
Qu servidor Web se debe usar?
Qu lenguaje de programacin utilizar?
1.4.5. Perspectivas de negocio
Se prevn cambios para los usuarios existentes?
Quines sern los nuevos usuarios?
Existen nuevos requerimientos?
Cmo es el impacto de los nuevos requerimientos sobre las caractersticas anteriores?
8
Fundamentalmente, una de las principales razones que se esgrimen para migrar a la Web la constituye el hecho de que los sistemas y las aplicaciones basados en Web hacen posible que una gran cantidad de usuarios pueda acceder a las mismas independientemente del lugar donde se encuentre.
As, cuando los sistemas crecen en funcionalidad, y los usuarios que acceden a los mismos tambin, es impensable hacer frente a estos desafos con los sistemas distribuidos tradicionales. Es necesario, no obstante, tener en cuenta los interrogantes planteados anteriormente para poder realizar el proceso de migracin de estos sistemas a la Web, siguiendo un enfoque disciplinado a los efectos de la construccin de una arquitectura slida que pueda ser eficientemente mantenible y configurable en su evolucin.
1.5. Problemas con la arquitectura Cliente/Servidor
Una vez que se ha logrado, de acuerdo a la metodologa aplicada, realizar una buena especificacin de requerimientos para el sistema a migrar, debe considerarse prioritaria la seleccin de una buena arquitectura para el mismo.
El objetivo de esta nueva arquitectura es el de facilitar el mantenimiento y posibilidad de escalabilidad del nuevo sistema, de modo que el mismo no se transforme solamente en una extensin del sistema cliente-servidor.
La arquitectura cliente servidor intenta equilibrar el proceso de una red entre computadoras especiales como son los servidores y, aquellas que envan, a travs de una interfase grfica de usuario (GUI) consultas a una base de datos que se encuentra en un servidor, y que se visualizan a travs de la interfase. Generalmente, cuando la red que soporta esta arquitectura distribuida es una red de rea local (LAN), la lgica de la aplicacin cliente reside en cada estacin de trabajo de acuerdo al perfil del mismo, por eso se lo denomina FAT CLIENT, o cliente pesado.
Se mencionan a continuacin algunos de los problemas ms comunes encontrados en las aplicaciones distribuidas tradicionales:
9
Programacin para un solo cliente (Windows).
No est preparado para la Web.
Control no centralizado.
Generacin de cuellos de botella en la base de datos.
Consume mucho recurso.
Limitado a recursos de hardware.
Cdigo embebido en los objetos.
Falta de control de las conexiones a las bases de datos.
Los clientes tienen administracin del negocio.
Fallas en la seguridad.
Asimismo, cabe mencionar que al momento de recoger los datos y las aspiraciones del cliente durante la fase del estudio preliminar surge un punto de decisin en el que resulta necesario considerar diferentes aspectos referentes a las aplicaciones a migrar, tales como:
Lenguajes de programacin de las aplicaciones.
Organizacin de los datos.
Expectativas de evolucin de la aplicacin.
Frecuencia e importancia de los cambios futuros.
Necesidad de modernizacin y agilidad ante futuros cambios.
Existencia de productos de emulacin en la plataforma abierta.
Segn el factor que se considere existen dos alternativas posibles:
Reubicacin de la aplicacin en la nueva plataforma utilizando productos de emulacin.
Transformacin/migracin de la aplicacin a un nuevo entorno de programacin.
Como el nuevo entorno de programacin para la Web exige un conocimiento profundo de nuevas tecnologas, es necesaria una previa capacitacin de los recursos humanos disponibles, as como la adquisicin de nuevo hardware (servidores y Workstations) para poder efectuar un desarrollo acorde a las
10
exigencias de las NTICs (nuevas tecnologas de la informacin y las comunicaciones).
1.6. Beneficios del proceso de migracin
Es esencial que para el xito del proceso de migracin, se cumpla con la funcionalidad requerida dentro del dominio de aplicacin establecido, para lo cual el usuario debe comprender el alcance de la misma y entender que el sistema anterior satisfaca parcialmente los requerimientos especificados e implementados para el nuevo sistema migrado.
De esta forma, los costos involucrados en el proceso de migracin deben ser sopesados contra los beneficios logrados, teniendo en cuenta adems una estimacin de la posibilidad de fallas durante el desarrollo y la implementacin del mismo.
Entre los principales beneficios asociados al proceso de migracin, cabe citarse:
Reduccin de costos. En una arquitectura Web, las tareas de administracin y mantenimiento del software se realizan en un solo punto y no en cada uno de los clientes.
Mejora de la productividad: un entorno ms amigable tanto para los desarrolladores como para los usuarios y el uso de nuevas funcionalidades.
Mayor accesibilidad: posibilidad de integracin con portales corporativos con el nico requisito de disponibilidad de un navegador o un dispositivo wireless.
Se puede acceder en este caso, en tiempo real, a informacin y herramientas antes slo disponibles para minoras a travs de terminales especficos. Gracias a la tecnologa Web el acceso se realiza a esos mismos sistemas desde cualquier terminal a travs del navegador.
Mantenimiento de la inversin: se conservan y reutilizan los conocimientos esenciales de los desarrolladores y usuarios sobre los
11
actuales desarrollos, por lo que el proceso de migracin aprovecha al mximo las capacidades existentes.
Posibilidad de reutilizacin del cdigo actual y de la documentacin existente a la migracin.
Por ltimo puede citarse la integracin de los sistemas migrados a la Web con los otros sistemas o aplicativos de los usuarios en lnea y los recientes servicios ofrecidos por la Web 2.0 (wikis, blogs, foros, ecommerce, etc.).
12
Captulo II
METODOLOGA PARA LA MIGRACIN DEL SISTEMA
En este captulo se presenta en primer trmino un metodologa para el conocimiento del nuevo sistema a migrar, luego, se presenta una metodologa para el conocimiento del nuevo sistema que ya ha sido migrado, y para este ltimo se pone el foco en la arquitectura cliente servidor, en la tecnologa Web y en las reglas de negocio que deben ser reusadas para abordar el proceso de migracin.
2.1. Metodologa propuesta de anlisis lgico y fsico del sistema a migrar
Se presenta a continuacin la metodologa para conocer los detalles de la arquitectura y diseo del sistema anterior, adems de las limitaciones tecnolgicas y de las reglas de negocio existentes en el momento de su construccin
2.1.1. Reconstruccin de la especificacin de requerimientos
Se asigna mucha importancia a la reconstruccin de la especificacin de requerimientos del sistema a ser migrado. Obviamente, la profundidad con la que pueda cumplirse esta tarea depender de cada caso, y la antigedad del sistema ser seguramente uno de los factores determinantes.
13
2.1.1.1. Estudio Preliminar
Realizar un anlisis exhaustivo del sistema original, utilizado para ello tcnicas de entrevistas a personas que hayan participado del mismo, desde el rea tcnica al rea operativa. Recopilar toda la documentacin disponible, incluyendo manuales de procedimientos, y analizar las reglas de administracin del sistema, caractersticas generales, perfiles, procesos, etc.
2.1.1.2. Reconstruccin.
Clasificar y ordenar toda la informacin testimonial y documental que pueda haberse obtenido en la etapa anterior.
2.1.2. Descripcin de la dimensin funcional.
La dimensin funcional es el eje de las etapas de anlisis y diseo, tanto de las metodologas estructuradas como orientadas a objetos, por lo que su correcta definicin es esencial en todo el proceso de validacin de un sistema.
2.1.2.1. Elaboracin del diagrama de contexto
Establecer las formas del sistema con los otros sistemas y agentes externos que se vinculan con el mismo mediante un Diagrama de Contexto. Este diagramas de contexto es un caso especial de diagrama de flujo de datos, denominado de nivel 0, que representa globalmente al sistema como una sola burbuja y donde un proceso nico define la frontera o marco del anlisis con el sistema externo As se definen las interfaces del sistema con el resto del universo.
14
2.1.2.2. Anlisis de comportamiento del sistema
Confeccionar la lista de eventos o acontecimientos que recibe el sistema y a los cuales debe darse respuesta, precisando en cada caso la naturaleza del evento y el tipo de respuesta esperado. Una vez completada esta lista se podrn establecer los escenarios que componen los distintos subsistemas del sistema a migrar y se completar el estudio de su comportamiento.
2.1.2.3. Construccin de diagramas de flujo
A partir de las tareas identificadas se deben desarrollar diagramas que permitan estudiar los flujos de datos y sus relaciones y transformaciones con los distintos procesos asociados. El diagrama de flujo de datos es una tcnica que representa el flujo de informacin y las transformaciones que
se aplican a los datos al moverse desde la entrada hasta la salida. Cada proceso, representado por una burbuja, puede refinarse en otros Diagramas de flujo para mostrar un mayor detalle.
2.1.2.4. Realizacin del modelo de casos de uso
El objetivo de esta tarea es especificar cada caso de uso identificado en el anlisis del comportamiento del sistema, representado grficamente los escenarios involucrados. Para cumplir con este objetivo se construye el Modelo de casos de uso de trazo grueso de la aplicacin distribuida, identificndose las relaciones entre los mismos.
2.1.3. Descripcin de la dimensin esttica del sistema anterior
Normalmente, el modelo funcional conduce a una base solidad para completar luego la dimensin esttica del sistema.
15
2.1.3.1. Reconstruccin del modelo conceptual.
El modelo conceptual se utiliza para obtener una descripcin del dominio del problema real, no es una descripcin del diseo del software. Es usado como base para una vista unificada de los datos y se representa con un diagrama grafico de estructura esttica, con las distintas entidades que componen el diseo lgico del sistema, sus relaciones y cardinalidad.
2.1.4. Descripcin de la interfaz de usuario
La interfaz de usuario es uno de los aspectos que sufre gran impacto en la migracin de sistemas a entornos Web y por lo tanto esta interfaz debe ser descrita con el mayor detalle y cuidado.
2.1.4.1. Anlisis del modelo de interfaz de usuario
Representa la interfaz de usuario, mostrando las distintas pantallas que intervienen en la aplicacin a migrar y realizando un diagnstico sobre su presentacin y contenido la interfaz de usuario es la herramienta que entiende a ambos y es capaz de traducir los mensajes que se intercambian por medio de una acceso amigable, congruente con sus necesidades y adecuado a principios ergonmico.
2.1.4.2. Construccin del modelo del sistema
Se presenta, a travs del uso del lenguaje unificado de modelado (UML), las interacciones entre el usuario y la base de datos, mediante la utilizacin de modelos de frmulas y de componentes, para lo cual existe una entidad central que despliega la informacin al usuario mediante la carga de forms.
16
Un form es un programa con los elementos necesarios para que el cliente pueda interactuar con la base de datos. Posee un conjunto de objetos que permiten, entre otras cosas, desplegar nuevos formularios, cajas de texto para ingresar datos, combos para seleccionar informacin existente.
La organizacin de forms es representada por una asociacin jerrquica, cuyo destino es un conjunto de entidades forms dependientes unas de otras. La subdivisin en forms tiene una asociacin unaria, es decir, cada form pude recargar una y solo una childform por vez, constituyendo esto una desventaja con respecto a las web page. Cuando un botn en un form fuerza la carga de otro form, el form de destino se convierte en el form activo.
La interfaz existente entre los forms y la Base de Datos, es la que permite el uso del SGBD. El acceso se produce mediante una clase de componentes que provee los drivers nativos de conexin.
2.1.5. Descripcin de la arquitectura fsica y del software de base
2.1.5.1. Arquitectura fsica
Al describirse la arquitectura fsica del sistema a migrar deben considerarse dos aspectos principales:
Tipo y capacidad de unidades centrales, dispositivos de almacenamiento, caractersticas de monitores y otros perifricos de entrada y salida (lectoras de cdigos de barra, scanners, impresoras, tikeadoras, etc.).
Interconectividad entre los equipos (red LAN, WAN, etc.) en el grfico 1 puede verse el esquema descrito.
17
Grfico N 01
INTERCONECTIVIDAD
FUENTE: Wikipedia
ELABORACION: El Autor
2.1.5.2. Arquitectura del Software de Base y diagrama de componentes
Describir la plataforma, incluyendo sistema operativo, interfaz grfica, motor de base de datos y otras libreras.
2.1.5.3. Anlisis de la limitaciones del modelo anterior
Describir las limitaciones o restricciones que se presentan en el sistema a migrar, tales como el empleo de determinadas metodologas de desarrollo, lenguajes de programacin, normas particulares, restricciones de
18
hardware, de sistema operativo, etc. Debe adems considerarse que, con mucha frecuencia, la migracin de un sistema arrastra expectativas referidas a mejoras operativas y/o funcionales que resultan ajenas a la propia migracin pero que tambin deben ser consideradas.
2.2. Metodologa propuesta de anlisis lgico y fsico del sistema migrado
Otro de los pilares bsicos en el proceso de migracin es el conocimiento de las nuevas reglas de negocio que se presentan as como las caractersticas tecnolgicas necesarias para el sistema en la Web. Con tal fin se presenta a continuacin una metodologa para conocer los detalles de la arquitectura y diseo del sistema migrado a la Web.
2.2.1. Adecuacin de la especificacin de requerimientos
2.2.1.1. Estudio preliminar
Descripcin de los servicios generales que debe brindar el nuevo sistema, incluyendo aquellos que ofreca el sistema anterior, con el detalle de las nuevas reglas de gestin y la tecnologa a utilizar para la migracin.
2.2.2. Adecuacin de la descripcin funcional
2.2.2.1. Revisin del modelo funcional
En funcin del rediseo del modelo de casos de uso de la nueva aplicacin y de las reglas de administracin acordadas, deben introducirse modificaciones al esquema funcional, que se reflejar en el nuevo modelo de casos de uso y en las especificaciones que surjan del mismo.
19
2.2.2.2. Realizacin del modelo de casos de uso de la aplicacin Web
Las nuevas reglas de administracin que resultan de los requerimientos formales del nuevo sistema, plantean un nuevo modelo de casos de uso que atienda las modificaciones y agregados a la funcionalidad existente en la aplicacin GUI
En este nuevo modelo de casos de uso puede observarse el rehus de la funcionalidad de la aplicacin anterior y, la incorporacin de nueva funcionalidad a la aplicacin migrada, acompaada de un reordenamiento de la misma por la insercin de la nueva tecnologa.
2.2.3. Adecuacin de la descripcin de la dimensin esttica
2.2.3.1. Revisin del modelo conceptual
Se revisa el modelo conceptual de la aplicacin anterior a los efectos de establecer las nuevas entidades que lo componen, las que responden a la redefinicin de las funcionalidades existentes, a las nuevas reglas de negocio relevadas y a las exigencias de la nueva tecnologa a implementar.
Para superar las limitaciones existentes en el sistema a migrar, debe comprobarse la existencia de las nuevas reglas de gestin con la interaccin entre todos los actores que juegan un rol importante en el sistema, estas reglas deben estar escritas y aprobadas por los responsables de las reas involucradas.
20
2.2.4. Descripcin de la interfaz del usuario en la aplicacin Web
2.2.4.1. Anlisis del modelo de interfaz de usuario
La interfaz de usuario en la tecnologa Web es el browser, por lo que la misma debe contemplar, de acuerdo al usuario que va dirigido, un diseo basado en la funcionalidad y en la navegabilidad.
Una ventaja significativa en la construccin de aplicaciones web, es que soporten las caractersticas de los Browsers estndar, independientemente de la versin del sistema operativo instalado en el cliente. Esto significa que, en lugar de crear clientes para Windows, Mac, OS X, GNU/Linux, entre otros, la aplicacin es escrita una vez y es mostrada de la misma forma en todos los entornos desde donde se accede.
2.2.5. Revisin de la arquitectura fsica y del software de base
2.2.5.1. Arquitectura fsica
La arquitectura del sistema migrado, basado en la tecnologa web, se implementa generalmente en un modelo multicapa donde los usuarios remotos, a travs de su terminal y del navegador se conectan a internet a travs de distintos tipos de conexin RDSI, ADSL, Cable, Satlite, Redes inalmbricas, como se observa en el grfico 2.
21
Grfico N 02
COMPONENTES DISTRIBUIDOS DE LA APLICACIN WEB
FUENTE: Wikipedia
ELABORACION: El Autor
2.2.5.2. Arquitectura del Software de Base y diagrama de componentes
A continuacin se presenta los distintos componentes que permiten realizar la visualizacin y transferencia de la informacin en un sistema distribuido en la Web, de acuerdo a la arquitectura fsica detallada en el punto anterior.
22
Componentes:
Sistema Operativo con interfaz grfica.
Conexin remota a servidores (local o de internet)
Browser de navegacin.
Componentes de la aplicacin:
Paginas HTML.
Paginas para procesamiento de informacin (ASP, PHP; CLASS).
Scripts y archivos de cdigo del lado del cliente (VBScript, JavaScript, JSP, etc.).
Plantillas de diseo (CSS).
Componentes de comportamientos (OCX, DLL)
Manejo de imgenes (JPG, GIF, BMP, PNG).
Animaciones (AVI, SWF).
Sonido (WAV, MP3, etc.).
Transferencia de informacin (XML, XSL, XLT, etc.).
Archivos de configuracin y ocultos
Archivos inmodificables (PDF).
Facilidades de conexin a webcam.
23
Captulo III
ANLISIS DEL SISTEMA A MIGRAR
3.1. Aplicacin de la Metodologa para el anlisis del Sistema a Migrar
La descripcin del sistema sirve como punto de partida para comprender los requerimientos del sistema.
3.1.1. Estudio preliminar
3.1.1.1. Servicios prestados por el Sistema
Realizar el seguimiento y administracin de cada alumno que ingresa como aspirante, mientras es alumno regular, hasta que arriba a la condicin de egresado, con la obtencin de su ttulo. La administracin acadmica de la institucin Nuestra Virgen del Rosario en su conjunto y de las unidades acadmicas en particular, permite mediante el sistema, el registro de todas las actividades acadmicas como apoyo de las acciones operativas y de toma de decisiones, para producir datos acadmicos, de uso interno y con otros organismos.
3.1.1.2. Relacin con otros Sistemas
Caja, Biblioteca.
24
3.1.1.3. Alcance del Sistema
El sistema cubre los procedimientos relativos a la administracin de los alumnos de cada grado.
Matrcula
Inscripcin de materiales
Inscripcin de exmenes parciales y finales
Recepcin, devolucin y registro de actividades parciales obligatorias. Emisin de constancias par alumnos regulares
Mantenimiento de grado
o Suspensin y baja.
o Alta y reinscripcin.
o Cambio de especialidad
Consultas en general:
o Notas parciales y finales
o Fechas de exmenes finales o Horario de tutoras
o Habilitacin para rendir exmenes.
o Consulta de situacin financiera.
3.1.2. Caractersticas generales y reglas de administracin
3.1.2.1. Perfiles
El sistema puede administrar un conjunto de perfiles que son representativos de los distintos usuarios que acceden al mismo. Existen perfiles ya predeterminados como el del alumno y el del docente, y la posibilidad de definir uno especfico para un usuario especfico.
25
3.1.2.2. Auditoria.
La auditora es una funcin incorporada al sistema que permite obtener en forma automtica en registro de la actividad que realiz cada usuario en el sistema.
3.1.2.3. Programacin
La herramienta usada para su programacin fue Visual Basic
3.1.2.4. Base de Datos
Microsoft Access
3.1.2.5. Listado de procesos
El sistema permite al alumno hacer consultas e inscripciones tanto grados como en exmenes en forma remota, en terminales distribuidas en la institucin.
La inscripcin en materiales tiene como requisito previo la inscripcin en carrera, trmite que el alumno realiza personalmente en la oficina de alumnos, al completar un ficha de inscripcin abonar la matrcula.
La solicitud de equivalencias y certificados debe hacerse en forma manual a travs de la oficina de alumnos
Si el alumno cambia de especialidad, o modifica sus datos personales debe hacerlo a travs de la oficina de alumnos
Las notas de parciales pueden ser cargadas por los docentes, pero no las notas finales de los cursos.
26
3.1.2.6. Reglas de administracin
Estas reglas aseguran que la actividad de la organizacin se lleva a cabo de acuerdo a restricciones impuestas desde afuera (leyes y normas) o dentro de la propia organizacin. En este caso, en el momento del desarrollo del sistema anterior, no exista un reglamento del alumno que contemplara estas normas, pero la vigencia del plan de estudios de cada carrera impone, cuanto menos, el marco normativo del cursado de los cursos.
3.1.3. Descripcin de la dimensin funcional
3.1.3.1. Elaboracin del diagrama de contexto
Este diagrama sirve para establecer las entidades que suministran y obtienen informacin del sistema a travs de sus interfaces y cul es el tipo de informacin que circula entre el sistema y las mismas
Como se observa en el grfico 3, los agentes entidades externas que interactan con el sistema en una primera aproximacin son: alumnos, docentes y departamentos acadmicos. Existen otras entidades como las cuotas que permiten el cursado y son de consulta permanente, y, interfaz impresora mediante la cual el alumno obtiene su comprobante de inscripcin.
27
Grfico N 03
DIAGRAMA DE CONTEXTO
FUENTE: Autor
ELABORACION: Autor
3.1.3.2. Anlisis de comportamiento del sistema.
A fin de continuar con el uso de la metodologa estructurada, se realiza un anlisis del comportamiento de los subsistemas Identificacin de usuario y Men de opciones. Para cumplir con este objetivo se utiliza la tcnica de escenarios para cubrir las posibles interacciones del sistema con los usuarios, utilizndose para ello una descripcin del flujo de eventos que figura a continuacin.
28
3.1.3.3. Construccin del diagrama de flujo de datos - DFD
En el grfico 4 que se muestra a continuacin, puede observarse como cada proceso (representado por un burbuja) puede refinarse en otros DFDs de menor nivel para mostrar un mayor detalle en el flujo de datos y procesos.
En este caso pueden observarse las burbujas de mayor nivel con las funcionalidades principales de acuerdo a lo detallado en el punto anterior, y las burbujas de menor nivel que extienden la funcionalidad de las anteriores. En forma de intermediarias entre ambas figuran las burbujas de control que verifican la correcta transformacin de los flujos de datos.
Grfico N 04
DIAGRAMA DE FLUJO
FUENTE: El Autor
ELABORACION: El Autor
30
3.1.3.4. Realizacin del modelo de casos de uso de la aplicacin anterior
Grfico N 05
MODELO DE CASOS DE USO DE LA APLICACIN DISTRIBUIDA
Actividades
Obligatorias
Examenes Finales
Consultar
Inscripcin deEspecialidad
Inscripcin deExamenes
Alumno
Equivalencia
Inscribir ExamenEliminar Inscripcin
Inscribir Especialidad
Consultas Cuotas
Modificar Codigo
FUENTE: El Autor
ELABORACION: El Autor
3.1.4. Descripcin del modelo conceptual del sistema administrativo
En el grfico 6 se muestra un esquema conceptual de datos pertenecientes al sistema administrativo. Este modelo se obtuvo de
31
observar los diagramas de entidad-relacin existentes utilizando una visin orientada a objetos, ya que se rescataron las principales entidades (u objetos) que se muestran en la grfico 6, teniendo en cuenta adems los distintos (o mtodos) del sistema por ejemplo el alumno pasa de estado activo a inscrito una vez que complet su ficha de inscripcin (en exmenes).
Bsicamente al migrarse al sistema en Web, la base de datos relacional no cambio su estructura de tablas, aunque si se incorporaron distintos servicios Web que se detallan en las pginas siguientes.
Grfico N 06
MODELO CONCEPTUAL
AlumnoGradoSelecciona
CompletaFicha deIncluye
Especialidad
Inscripcin
Mesa degeneraInscripcin enrealiza
ExamenesExamenesrealiza
EvaluacinContieneInscripcin en especialidad
asigna
selecciona
DocenteincluyeHorario especialidad
FUENTE: El Autor
ELABORACION: El Autor
32
3.1.5. Descripcin de la interfaz del usuario
3.1.5.1. Anlisis del Modelo de Interfaz del Usuario
En el caso de este sistema administrativo, la interfaz fue desarrollado con pantallas o ventanas con mens de opciones estrictamente jerrquicos, los que proporcionan al usuario una lista de las selecciones disponibles. El usuario no necesita conocer el sistema pero si necesita saber que tarea debe ser realizada.
El espacio de diseo de la interfaz es de dos dimensiones. En el caso de este sistema, solo se permite la utilizacin del teclado numrico y teclas de movimiento del cursor, as como tambin las teclas ENTER Y ESC, adems de FIN. El color aade una nueva dimensin a la facilidad de uso de la pantalla, para atraer la atencin del usuario al facilitar la separacin de componentes de la pantalla y acentuar las diferencias.
La crtica a realizar a esta interfaz se presenta en el men principal, en el que no existe la suficiente separacin jerrquica entre las opciones de consulta y las de actualizacin. Por ejemplo, eliminar inscripcin en Materia, debera estar dentro del grupo de actualizacin y, las consultas dentro de la misma opcin de consulta, por ejemplo: cronograma de actividades y consulta de situacin arancelaria figuran como una opcin nueva dentro del Men de Opciones, y no, dentro de las consulta.
A continuacin, en las siguientes figuras, presentamos las distintas pantallas del Men administrativo del alumno, desde el ingreso al sistema, men de opciones, entre las
que pueden seleccionarse consultas, Inscripciones en exmenes, listado de exmenes, cronograma de
33
actividades, consulta de situacin financiera y Modificacin de cdigo.
Grfico N 07
MEN PRINCIPAL DEL SISTEMA DE MATRCULA
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
34
Grfico N 08
INTERCONECTIVIDAD
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
Grfico N 09
INSCRIPCIN DE ALUMNOS
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
35
Grfico N 10
CREACIN DE CURSOS
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
Grfico N 11
ASIGNACIN DE CURSOS
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
36
Grfico N 12
ESTABLECER VACANTES
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
Grfico N 13
REPORTE DE ALUMNOS MATRICULADOS
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
37
3.1.5.2. Construccin del modelo del sistema
Para realizar un estudio comparativo entre ambas aplicaciones, se propone la construccin de un modelo empleando el lenguaje UML
La entidad central es el Modulo Principal, el cual despliega la informacin al usuario mediante la carga de forms.
Para acceder a l, previamente se toman los recaudos necesarios de seguridad de acceso, a travs de un pequeo form denominado Login. Este Login se autocargar hasta un mximo de tres veces cuando ocurran intentos fallidos de acceso y en caso contrario desplegara el Modulo.
Mientras que el contenido del FormRegistro, que se utiliza para el ingreso de datos, es esttico y fijo el contenido del formConsulta es dinmico determinado por el puesto de trabajo y puede depender de la informacin provista por el usuario a travs de campos de entrada.
Para modelar estas dos alternativas existen dos subclases derivadas de la clase Modulo Principal: FormConsulta y FormRegistro. Cuando el contenido de un formdinmico depende del valor de un conjunto de variables de entrada, estos estarn contenidos en el atributo use de las clase componentes. Por otra parte un formesttico solo estar compuesto de campos que sern completados por el usuario para actualizar la Base de Datos.
La interfaz AccesoDatos existente entre los forms y la BaseDatos, es lo que permite el uso del SGBD. El acceso se produce mediante la clase componentes, la que provee los drivers nativos de conexin. Las validaciones
38
necesarias las realiza AccessoDatos y es la que permitir con la BaseDatos.
3.1.6. Descripcin de la arquitectura fsica y del software de base 3.1.6.1. Arquitectura fsica
La arquitectura de esta aplicacin se basa en la tecnologa cliente/servidor, la cual hace referencia a la conexin de ordenadores por medio de una red a los fines de descentralizar el procesamiento y utilizar fuentes de datos centralizadas. La arquitectura se orientaba a la conexin de PCs clientes (alumnos), con servidores conectados a un red, en nuestro caso servidor de aplicaciones y de datos.
Grfico N 14
DIAGRAMA DE COMPONENTES DE LA APLICACIN
UIAdmMotor de Base
Logica
de Datos
UIAdm
Procedimientos
Almacenados
ComponentTablas
es Logicos
Vista
EntidadAcceso
esDatos
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
3.1.7. Anlisis de las limitaciones del modelo anterior implementado
Operatividad: cualquier cambio efectuado en el sistema implicaba la reconfiguracin del mismo en cada PC. Las terminales asignadas eran
39
escasas en nmero por lo que los alumnos deban realizar largas esperas con el objetivo de consultar o inscribirse.
Mantenimiento: el mantenimiento de las PC en funcionamiento y la impresora asignada era permanente y exiga un control continuo por personal de soporte tcnico.
Servicios: los servicios prestados a los alumnos se limitaban a la administracin acadmica prioritaria, es decir consultas bsicas e inscripciones, razn por la cual el resto de los servicios deba realizarse en forma personal en el departamento de alumnos o en las distintas en forma personal en el departamento de alumnos o en las distintas dependencias, segn el trmite a realizar por el alumno.
Interfaz: la interfaz es primitiva, el espacio de diseo de la interfaz es de dos dimensiones, con mens estrictamente jerrquicos, con opciones limitadas que solo pueden seleccionarse a travs del teclado numrico.
40
Captulo IV
RESULTADOS DE LA MIGRACIN DE UNA APLICACIN DISTRIBUIDA A UN
ENTORNO WEB
4.1. Aplicacin de la metodologa para el anlisis del sistema migrado
La descripcin del sistema sirve como punto de partida para comprender los requisitos del mismo.
Adecuacin de la especificacin de requerimientos
4.1.1. Estudio preliminar
4.1.1.1. Servicios prestados por el sistema
Realiza el seguimiento y administracin de los alumnos, desde que ingresan al curso y se matriculan.
Brinda al alumno los servicios, a diferencia del sistema anterior que slo lo habilitaba para consultas sobre su actividad acadmica e inscripcin en materias y exmenes.
El alumno, a travs de su clave, puede hacer uso de muchos otros servicios que se detallan a continuacin y a los que se accede a travs del sitio Web dentro del
41
subsistema de administracin de alumnos, al cual ingresa a travs de su clave
4.1.1.2. Relacin con otros sistemas
Biblioteca
Librera
Tesorera
4.1.1.3. Alcance del Sistema
El sistema comprende los procedimientos relativos a la gestin de los alumnos.
Uso de correo electrnico a travs de cuenta asignada por la Institucin. Control de datos personales
Matriculacin en curso de admisin.
Matriculacin en grado
Inscripcin en materias y obtencin de comprobantes direccionados por el sistema al correo electrnico del alumno. Reinscripcin anual a travs de formulario
Inscripcin en exmenes parciales y finales con obtencin de comprobantes Inscripcin en materias con obtencin de comprobantes
Envo de actividades parciales obligatorias
Emisin de constancias de alumno regular, examen parcial/final
Mantenimiento de cada grado.
Suspensin y baja.
42
Alta y reinscripcin.
Cambio de carrera y modalidad de carrera.
Consultas en general:
Notas parciales/finales.
De Planes de estudio y materias.
Del Reglamento del alumno y resoluciones decanales y rectorales.
Estado de actividades obligatorias.
Material de estudio.
Fechas de exmenes finales
Horarios de tutoras.
Habilitacin para presentar exmenes.
Materias a cursar.
Consulta de situacin financiera
Consulta de actividades recreativas y culturales.
Comunicacin con los departamentos acadmicos, de alumnos y docentes.
4.1.1.4. Caractersticas tecnolgicas
a. Programacin
La herramienta usada para la programacin es PHP.
b. Base de Datos
MYSQL
43
4.1.1.5. Reutilizacin de requisitos en el proceso de migracin a la Web
La reutilizacin de requisitos es un enfoque importante en el proceso de migracin, ya que no slo se aprovecha el conocimiento del sistema anterior, sino que adems permite identificar los requisitos nuevos y aquellos sujetos a cambios en el nuevo sistema.
Como los requisitos representan el conocimiento de un dominio particular, y ste se refiere a un rea funcional diferenciable dentro de un contexto dado, en este caso, ese contexto es la Universidad, y el dominio es el Subsistema de Administracin de Alumnos, sobre el cual se aplica este enfoque
Debido a la necesidad del conocimiento de este dominio para aplicar el enfoque de migracin al nuevo sistema, se propone dividir el dominio en dos subdominios, ambos basados en los requisitos de ambos sistemas (anterior y actual). La comparacin de estos subdominios se realiza mediante analoga basada en escenarios y casos de uso.
Con el objetivo de abordar este problema basado esencialmente en la utilizacin de modelos aplicando UML, se observa que este enfoque se acerca a la Metodologa. Del estudio realizado es posible rescatar las siguientes caractersticas:
UWE es una propuesta basada en el proceso unificado y UML, pero adaptados a la Web
En requisitos, separa las fases de captura, definicin y validacin
44
Hace adems una clasificacin y un tratamiento especial dependiendo del carcter de cada requisito
Grfico N 15
MODELO DE REQUISITOS BASADO EN DOMINIOS
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
4.1.1.6. Previsiones para superar las limitaciones comprobadas en el sistema original
Las nuevas reglas de administracin surgen del reglamento del alumno que figura en la pgina Web de la institucin. A continuacin se sintetizan las ms relevantes:
Para obtener la condicin de alumno de la carrera o curso, deber estar inscrito o reinscrito en la carrera o curso que se dicte en la facultad correspondiente y estar habilitado, condicin que se mantiene mientras no se registre un atraso mayor a una cuota vigente.
45
Los alumnos debern concretar anualmente la reinscripcin en la facultad que corresponda, abonando la matrcula respectiva. Es requisito para realizar el trmite de reinscripcin en la carrera mantener la condicin de regular.
Para mantener la condicin de alumno, se deber aprobar, como mnimo, dos asignaturas correspondientes a la currcula de la carrera que cursa dentro del ao acadmico.
Efectuar la reinscripcin anual.
Es obligatorio inscribirse en las asignaturas a cursar.
Los requisitos para dicha inscripcin son
Estar inscrito o reinscrito en la carrera, segn el caso
Cumplimentar el rgimen de condiciones de cursado vigentes
El alumno acceder a la condicin de regular en una asignatura, aprobando las actividades obligatorias previstas en la misma que establezca cada facultad
La condicin de regular en la asignatura habilita el acceso al examen final de la misma el caso de que se produzca la prdida de la condicin de alumno por cualquiera de las causas mencionadas anteriormente, se invalidar para el causante cualquier registro de calificaciones de actividades obligatorias pertenecientes a las asignaturas en las que no haya alcanzado la regularidad correspondiente
Del anlisis de las reglas de administracin del nuevo sistema puede determinarse la existencia de estados bien defiinidos en la condicin del alumno, como se observa en el grfico 16.
46
Grfico N 16
DIAGRAMA DE ESTADO DEL SISTEMA DE ADMINISTRACIN
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
4.1.2. Adecuacin de la descripcin funcional
4.1.2.1. Revisin del modelo funcional
El esquema funcional del sistema anterior se ampla con el agregado de funciones los correspondientes a la interaccin de un alumno con el portal de la universidad.teraccin
El mismo le permite, no slo realizar las funciones comunes referentes a su condicin de alumno sino tambin realizar trmites varios, descargar software, realizar encuestas en lnea, obtener sus comprobantes de inscripcin y de pago en forma virtual, adems de ser partcipe, a travs de las Noticias, de cursos, novedades y becas que ofrece el instituto
47
Por otro lado, a travs de la pgina e identificndose como alumno puede acceder accede las aulas virtuales de las materias en las cuales est inscrito y acceder al Plan de Estudios de las carreras que se cursan.
Las opciones de consulta le permiten a su vez poder conocer el estado de su currcula, el estado de las materias y exmenes y los trmites que ha realizado.
4.1.2.2. Realizacin del modelo de casos de uso de la aplicacin Web
Funcionalidades en la aplicacin Web; asimismo, que existen funciones principales que han sido obtenidas en el nuevo sistema a partir de la aplicacin tradicional, las que se demarcan con una tonalidad ms intensa
4.1.3. Adecuacin de la descripcin de la dimensin esttica
Revisin del modelo conceptual
El modelo conceptual construido de la aplicacin anterior se revisa y se modifica para que se reflejen las nuevas entidades que lo componen en funcin de la redefinicin de las funcionalidades y del agregado de nuevas entidades que responden a las mismas, con el objeto de adaptar el mismo a las nuevas reglas de negocio relevadas y a las exigencias de la nueva tecnologa a implementar
48
Grfico N 17
DIAGRAMA DE CASOS DE USO DE LA APLICACIN WEB
CalificacionesActividades Obligatorias
Seleccionar GradoDatos PersonalesExamenes Finales
Ver Aula VirtualEquivalencia
Ver ReglamentoConsultarEspecialidades inscritas
AvisosCorrespondencia de Planes
Material de estudio Horarios
AlumnoTramites
ComunicarInscribir
EspecialidadReinscribir en Especialidad
Depto Alumno
Modificar Contrasea Web MasterExamenes FinalesCancelar Inscribir
Actividades Varias
Servicios AdicionalesServicios Varios
Personalizar menu
Eventos Especiales
Descarga SoftwarePreguntas Freguntasapariencia
Personalizar
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
Grfico N 18
MODELO CONCEPTUAL DE LA APLICACIN WEB
Alumnogenera
rinderesponde
realizaMesas d
Inscripcion cursoExamen Final
rindeseleccionacorrespondecorresponde
ActividadEspecialidadtieneCorrelativa ex
Obligatoriaselecciona
completacontieneCursopertenece
Grado
MatriculaModulos
corresponde
realiza
Tramites Academicos
dejaTrazas de autogestion
realizaLogin
completaEncuesta
FUENTE: I.E. Nuestra Virgen del Rosario
ELABORACION: El Autor
50
4.1.4. Descripcin de la interfaz de usuario en la aplicacin web
4.1.4.1. Anlisis del modelo de interfaz de usuario de la aplicacin Web
A continuacin se muestran las pantallas diseadas para la interfaz con el usuario en la aplicacin Web, las opciones se encuentran divididas de acuerdo a la funcionalidad prevista. As se presentan las opciones de consulta de alumnos (datos personales, calificaciones, trmites, etc.) e institucional (horarios de materias, exmenes, etc.). En la opcin Inscripcin puede observarse en Materia, Examen o preinscripcin.
A travs del men el alumno puede Enviar actividades obligatorias, Cancelar su inscripcin en materias, disponer de Servicios como publicar avisos, configurar y descargar programas, etc. Puede seleccionar Comunicarse para hacerlo con los departamentos o el Webmaster, es decir toda la funcionalidad prevista y organizada.
Si bien se presentan las pantallas principales del sistema, su diseo y los contenidos funcionales hacen que la navegacin sea sencilla orientada bsicamente a las necesidades de los alumnos. Gracias a la estructura de su men permite seleccionar cualquier opcin sin necesidad de seguir una estructura jerrquica establecida.
El diseo se respetaron los colores institucionales y las pginas siguen los estndares establecidos por la W3C (Consorcio World Wide Web) que es un consorcio internacional donde las organizaciones miembro y el pblico en general, trabajan conjuntamente para desarrollar.
51
En la interaccin se brindan opciones de cambio de la configuracin del browser en la mquina local y, la posibilidad de efectuar descarga del software necesario para operar en el sitio web.
4.1.4.2. Construccin del modelo de la aplicacin web
Para describir la aplicacin Web genrica se utiliza un modelo, en el cual la entidad central es el Browser. Los navegadores Web utilizan protocolos de comunicacin tales como el http, https y ftp que interactan con WebServer mediante servicios del tipo Apache o IIS (Internet Information Server), para la administracin de informacin, como es nuestro caso; a la vez que autentican servicios y administran cookies. En el modelo a desarrollar, este servicio tomar contacto con un ApplicationServer que contar con una interfaz de AccesoDatos para administrar la informacin con la BaseDatos
Los frames y otros Componentes facilitan la organizacin y la interaccin. La navegacin de una pgina a otra es modelada por la asociacin a s misma de la clase Paginas. El acceso a las pginas se realiza mediante autenticacin a travs de la clase Login, que tendr la misin de permitir la navegacin en el sitio.
Mientras que el contenido de una pgina Web esttica es fijo, el contenido de una pgina dinmica es determinado en tiempo de ejecucin por el Server y puede depender de la informacin provista por el usuario a travs de campos de entrada. Para modelar estas dos alternativas existen elementos contenidos en la clase Componentes. Esta clase contiene Scripts, XML para la transferencia de datos, componentes ActiveX, Applets, Flash Movies, JavaBeans,
52
etc. El contenido de una pgina dinmica depende del valor de un conjunto de variables de entrada provistas por el usuario.
La organizacin en frames es representada por la asociacin split into, cuyo destino es un conjunto de entidades frames. La subdivisin en frames puede ser recursiva y cada frame tiene una asociacin unaria con la pgina Web inicialmente cargada dentro del frame (ausente en el caso de subdivisin recursiva dentro de los frames). Cuando un link en una pgina Web fuerza la carga de otra pgina dentro de un frame diferente, el frame de destino se convierte en el miembro de datos de la clase opcional de asociacin Load Page Into Frame.
4.1.5. Revisin de la arquitectura y del software de base
4.1.5.1. Arquitectura
La disciplina de diseo de interfaces experiment un gran impulso con el desarrollo de aplicaciones Web para uso masivo por grupos de usuarios de mbito universal y bajo fuertes restricciones de velocidad debido al ancho de banda existente. En esta arquitectura a la cual se migr, una mquina cliente realiza peticiones a una mquina servidora y sta a su vez a otros servidores para satisfacer la peticin original, el nivel lgico es independiente de la capa fsica y de la presentacin (browser), pudiendo ambos configurarse en mquinas servidor independientes. Esta arquitectura fue mejorada a su vez con una arquitectura multicapa, en donde cada nivel fsico se responsabiliza de una funcin del sistema.
53
4.1.5.2. Diagrama de componentes de la aplicacin web
En este grfico es posible observar cmo funciona la nueva aplicacin luego de la reingeniera. En ella, a diferencia de la GUI Application, se muestran marcadas las tres capas del proceso, tal como se detallan a continuacin.
a. Cliente
El cliente accede al sistema de manera remota mediante un SO con interfaz grfica a travs de Internet. En esta capa, el componente principal es el Browser de navegacin el cual despliega pginas HTML encargadas de la interfaz con el usuario y que se representa mediante el componente HTML UIAdm. Estas pginas contienen componentes de animacin FlashPlayer ComponentesDinamicos lo cual permite que el sitio no sean pginas fras y desagradables a la vista del usuario. El componente ASP LogicaUIAdm contiene algunos componentes de JavaScript que se descargan y funcionan en la mquina del cliente
b. Servidor Web
En esta capa, el componente principal es IIS (Internet Information Server) para el caso de la tecnologa Microsoft. En ese componente se encuentran las polticas de acceso y concurrencia de clientes remotos al uso de la aplicacin. El componente ASP LogicaUIAdm contiene la lgica de negocio y, en conjunto, con el componente ActiveX Entidades que realiza la gestin entre las entidades del sistema utilizan los objetos COM+ para el manejo de datos. Luego se administra el acceso a la Base de Datos mediante el componente ADO AccesoDatos que toma
54
la funcionalidad de conceder el permiso de acceso por medio de drivers ODBC.
c. Servidor de Base de Datos
En esta ltima capa, el componente principal es el Motor de Base Datos que contiene el servicio principal para la administracin de datos. Los componentes asociados son las Tablas donde se halla la organizacin de la informacin, las Vistas donde se encuentran las consultas ms comunes, y los Procedimientos Almacenados donde estn todos los Script para la administracin de datos. Todo este manejo lo realiza T-SQL (Transact SQL) propio del motor utilizado. En esta capa el SGBD tambin maneja la concurrencia, mediante permisos otorgados por el DBA a determinado nmero de operaciones por vez; de esta manera, se garantiza seguridad y consistencia en la informacin evitando que los servidores colapsen.
En la vista fsica de las tres capas de la aplicacin Web. Es posible observar la reutilizacin de los componentes de la Aplicacin GUI en la Aplicacin Web. Dentro de estos nodos, se ejecutan procesos, servicios y/o componentes y sus relaciones de dependencia, como por ejemplo el Internet Explorer muestra la pgina HTML que corresponde a la presentacin o Interfaz del Usuario de la aplicacin
55
Captulo V
EVALUACIN
5.1. Plan de pruebas
Para comprobar la correcta funcionalidad del sistema, as como el grado al cual se cumplieron los objetivos especficos planteados al inicio del desarrollo, se realizaron pruebas enfocadas en los siguientes aspectos: funcionalidad, compatibilidad, y tiempo de respuesta. En las siguientes secciones se explica el objetivo de cada prueba realizada, se presentan sus resultados y se concluye si el sistema cumple o no con las metas fijadas en el rea examinada.
5.2. Pruebas de funcionalidad
De acuerdo con Pressman, las pruebas de caja negra, llamadas tambin de comportamiento, se encuentran enfocadas en los requisitos funcionales del software y permiten al desarrollador centrarse en la coherencia de las entradas y salidas del sistema sin preocuparse de la estructura interna de la aplicacin examinada.
Este tipo de pruebas se aplic con el objetivo de localizar fallas funcionales en el sistema, al identificar situaciones en las que las respuestas de ste a determinadas acciones del usuario no se apegan a las especificaciones establecidas.
56
Las pruebas se enfocaron en las siguientes operaciones: acceso al sistema, consulta de cursos equivalentes, consulta de secciones disponibles, alta, baja y cambio de una seccin, consulta de la lista de cursos inscritos, consulta de la vista tipo horario, impresin del horario, consulta de informacin de una seccin inscrita y salida del sistema. Cada operacin fue examinada con diferentes entradas del usuario para determinar que los resultados obtenidos fueran consistentes bajo cualquier situacin con aquellos establecidos en el anlisis de requerimientos.
Los resultados se analizan con detalle en la siguiente seccin, sin embargo a manera de resumen cabe resaltar que el veredicto final resulta positivo, ya que el sistema se desempe conforme a lo esperado bajo todas las condiciones examinadas como lo corroboran las tablas que se presentan enseguida
5.3. Pruebas a detalle
Cuadro N01
ACCESO AL SISTEMA DE INSCRIPCIONES
PruebaEntrada o accin deResultado esperado del sistemaConfirmacin
usuario
Prueba 1. Acceso al sistema de inscripciones.
NmerodeEl sistema permite el acceso al
P 1.1estudianteCorrectousuario,identificndoloSI
Y Cdigo incorrecto.correctamenteymostrndole
pantalla de bienvenida.
NmerodeEl sistema niega el acceso y
P 1.2estudiante correcto ymuestralapginadeentradaSI
Cdigo incorrecto.nuevamente.
P 1.3NmerodeEl sistemaniegael acceso ySI
estudiante correcto ymuestralapginadeentrada
57
Cdigo nulo.nuevamente.
NmerodeEl sistema niega el acceso y
P 1.4estudiante incorrectomuestralapginadeentradaSI
y Cdigo correcto.nuevamente.
P 1.5NmerodeElsistemaniegaelaccesoy
estudiantenuloymuestralapginadeentradaSI
Cdigo correcto.nuevamente.
P 1.6NmerodeElsistemaniegaelaccesoy
estudiante incorrectomuestralapginadeentradaSI
y Cdigo incorrecto.nuevamente.
NmerodeEl sistema niega el acceso y
P 1.7estudiantenuloymuestralapginadeentradaSI
Cdigo nulo.nuevamente.
FUENTE: Pruebas de acceso al sistema
ELABORACIN: El autor
58
Cuadro N02
OPERACIONES DE CONSULTA
PruebaEntrada o accin deResultado esperado del sistemaConfirmacin
usuario
Prueba 2. Operaciones de consulta de cursos equivalentes a una materia.
P 2.1MostrarloscursosEl sistema muestra la informacin
equivalentesaunade los cursos equivalentes a unaSI
materia.materia.
P 2.2OcultarloscursosEl sistema remueve la informacin
equivalentesaunade los cursos equivalentes cuando
SI
materia.se quita la seleccin o cursor
sobre una materia.
P 2.3Mostrarlas seccionesEl sistema muestra la informacin
disponiblesenunde las secciones disponibles paraSI
curso.el curso seleccionado.
FUENTE: Pruebas de consulta de cursos equivalentes y secciones disponibles ELABORACIN: El autor
59
Cuadro N03
OPERACIONES DE INSCRIPCIN
PruebaEntrada o accin deResultado esperado del sistemaConfirmacin
usuario
Prueba 3. Operaciones de inscripcin de una seccin ofrecida
InscribirunaseccinEl sistema inscribe la seccin
con cupo disponible deseleccionadaactualizala
P 3.1un curso. ConfirmarlainformacindelasseccionesSI
inscripcincuandoelinscritas.
sistema lo requiere.
InscribirunaseccinEl sistema no inscribe la seccin
con cupo disponible deelegida.
P 3.2un curso. CancelarlaSI
inscripcincuandoel
sistema lo requiere.
Inscribir una seccin deEl sistema no inscribe la seccin
un curso cuyo cupo seelegida, SI muestra un aviso
P 3.3llenaantesdeadvirtiendoal usuarioquela
completar la operacin.seccin estllenay actualizalaSI
Confirmarlainscripcininformacindesplegadapara
cuandoelsistemaloevitar posterioresintentossobre
requiere.la seccin llena.
60
InscribirunaseccinEl sistema no inscribe la seccin
con cupodisponibley muestra un aviso advirtiendo al
P 3.4cuyohorarioseusuario que el horario de la
traslapaconotraseccin elegida se traslapa con elSI
seccin ya inscrita.de una materia ya inscrita.
FUENTE: Pruebas de alta de una seccin
ELABORACIN: El autor
Cuadro N04
OPERACIONES DE BAJA DE UNA SECCIN PREVIAMENTE INSCRITA
PruebaEntrada o accin deResultado esperado delConfirmacin
usuariosistema
Prueba 4. Operaciones de baja de una seccin previamente inscrita
Dar de baja una SeccinEl sistema da de baja la
P 4.1uncursoinscrito.seccinseleccionadaySI
Confirmar la bajacuandoactualiza la informacin de las
el sistema lo requiere.seccionesinscritas.
Dar de baja una seccinEl sistema no da de baja la
P 4.2un curso inscrito. Cancelarseccin elegida.SI
la baja cuando el sistema
lo requiere.
FUENTE: Pruebas de baja de una seccin.
ELABORACIN: El autor
61
Cuadro N05
OPERACIONES DE CAMBIO DE UNA SECCIN INSCRITA.
PruebaEntrada o accin deResultado esperado del sistema Confirmacin
usuario
Prueba 5. Operaciones de cambio de una seccin inscrita.
CambiarunaseccinEl sistema realiza la baja de la
inscrita por otra con cuposeccinpreviamenteinscrita,
disponible.inscribe la seccin seleccionada
P 5.1y actualiza la informacin de lasSI
Confirmarelcambio
elsecciones inscritas.
cuandosistemalo
requiere.
CambiarunaseccinEl sistema no da de baja la
inscrita por otra con cuposeccinpreviamente inscrita ni
disponible.inscribe la seccin elegida.SI
P 5.2
Cancelarelcambio
cuandoelsistemalo
requiere.
CambiarunaseccinEl sistema no da de baja la
inscrita porotra cuyoseccinpreviamenteinscrita,
cupo se llena antes demuestra un aviso advirtiendo al
P 5.3completar la operacin.usuario que la seccinelegidaSI
est llena y actualiza la
Confirmarelcambio
informacin desplegadapara
cuandoelsistemaloevitar posteriores intentos sobre
requiere.la seccin llena.
FUENTE: Pruebas de cambio de una seccin inscrita
ELABORACIN: El autor
62
Cuadro N06
OPERACIONES DE VISUALIZACIN
PruebaEntrada o accin deResultado esperado del sistemaConfirmacin
usuario
Prueba6. Operaciones de visualizacin de la lista de materias inscritas,
consulta del horario e impresin del mismo.
Consultar lasEl sistema presenta una lista con las
P 6.1materias inscritas,secciones inscritas por el alumno,SI
cuando existenas como un conteo total de las
secciones inscritas.unidades de dichas secciones
ConsultarlasEl sistema indica al usuario que
materiasinscritas,antes de ver su horario debe
P 6.2cuandoannoinscribir alguna materia.SI
existensecciones
Inscritas.
Imprimir el horario.El sistema abre una nueva ventana
del navegador con el semestre
actual, nombre, matrcula y su
P 6.3horario. Despus muestra el cuadroSI
de dialogo de impresin del
navegador.
FUENTE: Pruebas de visualizacin de vista tipo lista y horario e impresin del horario ELABORACIN : El autor
Cuadro N07
CONSULTA DE INFORMACIN
63
PruebaEntrada o accin deResultado esperado del sistemaConfirmacin
usuario
Prueba 7. Consulta de informacin de secciones inscritas.
Seselecciona unaEl sistema presenta informacin de
P 7.1seccin inscrita.la seccin, profesor, salnySI
equivalencia as como una opcin
para dar de baja la seccin.
FUENTE: Pruebas de consulta de informacin de una seccin inscrita
ELABORACIN: El autor
64
Cuadro N08
SALIR DEL SISTEMA
PruebaEntrada o accinResultado esperado delConfirmacin
de usuariosistema
Prueba 8. Salir delsistema
P 8.1Seleccionarla opcinEl sistema muestra laSI
salirdelsistema.pgina de Login
Confirmar la seleccin
cuandoelsistema lo
requiera
P 8.2Seleccionarla opcinEl sistema permanece enSI
salir del sistema.la pgina actual.
Cancelar laseleccin
cuandoelsistema lo
requiera.
FUENTE: Pruebas de salida del sistema
ELABORACIN: El autor
Como se puede observar, la respuesta del sistema result consistente con lo esperado a lo largo de todos los casos examinados
5.4. Pruebas de compatibilidad
Estas pruebas se realizan con el fin de comprobar la compatibilidad del sistema con distintos navegadores web. Para que la aplicacin sea considerada como compatible con un navegador, el diseo de su interfaz grfica debe permanecer constante, sin sufrir grandes alteraciones o cualquier tipo de cambio que afecte o disminuya su funcionalidad. Por otro lado, el usuario debe poder realizar todas
65
las operaciones que ofrece el sistema de manera fluida, sin la presencia de mensajes sobre errores por parte del navegador. A continuacin presenta una tabla con los resultados de las pruebas de compatibilidad aplicadas siguiendo los lineamientos mencionado.
Cuadro N09
COMPATIBILIDAD
Sistema OperativoNavegadorVersinCompatibilidad
Microsoft
Windows XPMicrosoft Internet6.0SI
Explorer.
Windows XPMicrosoft Internet7.0SI
Explorer
Windows XPMozilla Firefox1.5SI
Windows XPMozilla Firefox2.0SI
LinuxMozilla Firefox1.5SI
LinuxMozilla Firefox2.0SI
Windows XPOpera9.0SI
Mac OSSafari2.0SI
FUENTE: Pruebas de compatibilidad
ELABORACIN: El autor
66
5.5. Pruebas de tiempo de respuesta
5.5.1. Pruebas a detalle
Con el objetivo de comprobar la capacidad del sistema para soportar mltiples accesos concurrentes sin sufrir una baja considerable en su rendimiento se realizaron pruebas de stress con el apoyo de la herramienta basada en JavaApacheJMeter (http://jakarta.apache.org/jmeter). Este software est diseado para realizar pruebas de carga sobre un sistema y brindar mediciones sobre su desempeo durante ellas.
Debido a que JMeter simula la interaccin del usuario con el sistema, es necesario programar cada operacin que se desea efectuar durante la prueba, indicando la ruta en el servidor para acceder al recurso, los parmetros que deben ser enviados, el tipo de mtodo que se utiliza para realizar la peticin y la respuesta que se espera del sistema.
Con estos datos JMeter realiza las operaciones indicadas necesidad de tener acceso a la interfaz grfica del sistema. En el caso del sistema de inscripciones, con la finalidad de efectuar una prueba realista, se programaron las operaciones del proceso completo de alta y posterior baja de las siete materias. Todas las operaciones de este proceso se programaron en el orden en que las ejecutara el sistema al estar interactuando con un estudiante. En total se obtienen 46operaciones por cada usuario como se aprecia en la siguiente tabla.
67
Cuadro N10
OPERACIONES
TipoNmero de
Operaciones
O1.Login1
O2.Consultar cursos equivalentes a uno2
expansible
O3.Consultar secciones disponibles de un16
curso
O4.Alta de una seccin7
O5.Baja de una seccin6
O6.Consultar lista de materias inscritas10
O7.Consultar horario de materias inscritas4
TOTAL46
FUENTE: Operaciones de las pruebas de robustez
ELABORACIN: El autor
68
La siguiente tabla muestra las caractersticas del servidor:
Cuadro N11
CARACTERSTICAS DEL SERVIDOR
Servidor
ProcesadorIntel Xeon E5504 @ 2.0 GHz
Memoria RAM8GB @1066MHz
Disco Duro500GB SATA 7,200 rpm
S.O.Windows Server 2003
Web ServerIIS 6.0
DBMSSQL Server 2005
FUENTE: Caractersticas tcnicas del servidor
ELABORACIN: El autor
69
Cuadro N12
PRUEBAS DE ESTUDIANTES
Taza de Llegada (ms)UsuariosNo. OperacionesTiempo promedio
por operacin (ms)
14617
1 usuario/ 200 ms523025
1 usuario/ 200 ms1046031
1 usuario/ 200 ms25115087
1 usuario/ 200 ms504600148
1 usuario/ 200 ms1506900285
1 usuario/ 200 ms2009200395
1 usuario/ 200 ms50023000692
FUENTE: Tiempo de promedio de todas las operaciones
ELABORACIN: El autor
CONCLUSIONES
Gracias a la metodologa utilizada, fue posible cubrir los objetivos propuestos para este proyecto, no obstante, parece conveniente revisar algunas de las recomendaciones y propuestas que ms influyeron en el desarrollo de este proyecto. Estas estn referidas a la migracin de sistemas a la Web y varias de las cuales fueron ya mencionadas a lo largo de este trabajo, en especial en los Captulos 2 y 3.
Con este fin, para cada uno de los principales aspectos de la migracin de Sistemas a la Web se comentan las principales propuestas y su influencia o vinculacin con el trab
top related