Proyecto Entorno Educativo Web

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.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.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


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


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


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


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


34

Grfico N 08

INTERCONECTIVIDAD



Grfico N 09

INSCRIPCIN DE ALUMNOS



35

Grfico N 10

CREACIN DE CURSOS



Grfico N 11

ASIGNACIN DE CURSOS



36

Grfico N 12

ESTABLECER VACANTES



Grfico N 13

REPORTE DE ALUMNOS MATRICULADOS



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



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



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



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



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



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.


P 1.4estudiante incorrectomuestralapginadeentradaSI

y Cdigo correcto.nuevamente.

P 1.5NmerodeElsistemaniegaelaccesoy

estudiantenuloymuestralapginadeentradaSI

Cdigo correcto.nuevamente.

P 1.6NmerodeElsistemaniegaelaccesoy

estudiante incorrectomuestralapginadeentradaSI

y Cdigo incorrecto.nuevamente.


P 1.7estudiantenuloymuestralapginadeentradaSI

Cdigo nulo.nuevamente.

FUENTE: Pruebas de acceso al sistema

ELABORACIN: El autor

58

Cuadro N02

OPERACIONES DE CONSULTA


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


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


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.


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


62

Cuadro N06

OPERACIONES DE VISUALIZACIN


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


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


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


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


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


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


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


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

Documents

Proyecto Entorno Educativo Web