UNIDAD 1 Fundamentos de La IWeb

INGENERÍA WEB MTI ROSA IMELDA GARCIA CHI

INGENIERÍA WEB

UNIDAD 1

FUNDAMENTOS DE LA IWEB

PRESENTA: MTI. ROSA IMELDA GARCÍA CHI

INSTITUTO TECNOLÓGICO DE CIUDAD VALLES


Introducción

La World Wide Web y la Internet que la alimentan son, posiblemente los desarrollos más importantes en la historia de la computación.

Estas tecnologías han llevado a todos (con cientos de millones más que eventualmente seguirán) a la era de la informática; además se han convertido en parte integral de la vida diaria en la primera década del siglo XXI


¿Pueden imaginar un mundo sin la Web?

• los primeros días del software

El crecimiento caótico de la tecnología tiene su

origen en otra era:


Era una época de poca disciplina pero enorme entusiasmo y creatividad.

Eran tiempos en que los programadores a menudo ingresaban a sistemas en conjunto a veces para bien a veces para mal

La actitud prevaleciente parecía ser:

• “hazlo rápido y entra en el campo; en el camino se entenderá qué es lo que realmente se necesita constuir”


Atributos de los Sistemas y

Aplicaciones basados en Web

INGENIERIA WEB

UNIDAD 1


Primeros días de la World Wide Web

Los “Sitios Web” consistían poco mas de un conjunto de archivos de hipertexto ligados que presentaban información mediante texto y gráficos limitados.

Conforme el tiempo pasó, el HTML aumentó al desarrollar herramientas (por ejemplo XML, Java) que permitieron a los ingenieros Web ofrecer capacidades de cálculo junto con información.

Nacieron los sistemas y aplicaciones basados en web (se les referirá de manera colectiva como WebApps).


En la actualidad las WebApps han evolucionado en sofisticadas herramientas de computación que no sólo proporcionan función por si mismas al usuario final, sino que también se han integrado con bases de datos corporativas y aplicaciones de negocios


En la gran mayoría de las WebApps se encuentran los siguientes atributos:

Intensidad de red

Concurrencia Carga

impredecible Desempeño

Disponibilidad Gobernada

por los datos Sensibilidad al

contenido Evolución continua

Inmediatez Seguridad Estética


Intensidad de Red

Una WebApp reside en una red y debe satisfacer las necesidades de una variada comunidad de clientes.

Una WebApp puede residir en la Internet (y en consecuencia, permitir una comunicación mundial abierta)

Alternativamente, una aplicación puede colocarse en una Intranet (lo que implementa la comunicación en una organización) o en una Extranet (comunicación inter-red)


concurrencia

Un gran número de usuarios puede tener acceso a la

WebApp al mismo tiempo.

En muchos casos, los patrones de uso entre los usuarios

finales variarán enormemente.


Carga impredecible

El número de usuarios de la WebApp puede variar en

órdenes de magnitud de día con día.

Un día, por ejemplo el lunes pueden mostrarse 100

usuarios, el martes pueden usar el sistema 10 000.


Desempeño

Si un usuario de WebApp debe esperar demasiado (para ingresar, para procesamiento en el lado del servidor, para formateo y despliegue en el

lado del cliente) puede decidir irse a cualquier otra parte


Disponibilidad

Aunque la expectativa de una disponibilidad del total es poco razonable, los usuarios de las WebApps populares con frecuencia demandan acceso sobre una base de “24/7/365”

Los usuarios en Australia o Asia pueden demandar acceso durante momentos cuando las tradicionales aplicaciones de software doméstico en Norteamérica pueden estar fuera de línea por mantenimiento.


Gobernada por los datos

La función primordial de muchas WebApps es usar hipermedia para presentar contenido de texto, gráficos, audio y video al usuario final.

Además, por lo general, las WebApps se utilizan para tener acceso a información que existe en bases de datos que originalmente no eran parte integral del ambiente basado en web (por ejemplo, comercio electrónico o aplicaciones financieras)


Sensibilidad al contenido

La calidad y naturaleza estética del contenido

sigue siendo un importante determinante de la calidad

de una WebApp


Evolución continua

A diferencia del software de aplicación convencional, que evoluciona a lo largo de una serie de planeadas liberaciones espaciadas cronológicamente, las aplicaciones Web evolucionan de manera continua.

No es raro que algunas WebApps (específicamente su contenido) se actualicen sobre una agenda minuto a minuto, o que el contenido sea calculado de manera independiente para cada solicitud.


Inmediatez

Aunque la inmediatez – la apremiante necesidad de poner software en el mercado rápidamente- es una característica de muchos dominios de aplicación, las WebApps con frecuencia muestran un tiempo para comercializar que puede ser cuestión de unos cuantos días o semanas.

Los ingenieros Web deben aplicar métodos de planeación, análisis, diseño, implementación y puesta a prueba que han sido adaptados a los apretados tiempos requeridos para el desarrollo de WebApps


Seguridad

Puesto que las WebApps están disponibles mediante el acceso a la red, es difícil, si no imposible, limitar la población de usuarios finales que pueden tener acceso a la aplicación.

Con la finalidad de proteger el contenido confidencial y ofrecer modos seguros de transmisión de datos, se deben implementar fuertes medidas de seguridad a lo largo de la infraestructura que sustenta una WebApp y dentro de la aplicación de la misma.


Estética

Una parte innegable de la apariencia de una WebApp es su presentación y la disposición de sus elementos

Cuando una aplicación se diseña para comercializar o vender productos o ideas, la estética puede tener tanto que ver con el éxito como el diseño técnico


En el trabajo IWEB es usual encontrar las siguientes categorías de aplicaciones


• se proporciona contenido de sólo lectura con navegación y enlaces simples

Informativo

• un usuario descarga información del servidor apropiado

Descarga


• el usuario personaliza el contenido según sus necesidades específicas Personalizable

• la comunicación entre una comunidad de usuarios ocurre por medio de cuartos de charla, tableros de anuncios o mensajería instantánea

Interacción


• la entrada con base en formularios es el principal mecanismo para las necesidades de comunicación

Entrada del usuario

• el usuario hace una solicitud (por ejemplo, realiza un pedido)que ejecuta la WebApp

Orientada a transacciones


• la aplicación proporciona un servicio al usuario; por ejemplo, lo asesora en la determinación del pago de una hipoteca

Orientada a servicios

• la aplicación canaliza al usuario hacia otro contenido o servicios web fuera del dominio del portal de la aplicación

Portal


• el usuario consulta una gran base de datos y extrae información

Acceso a una base de datos

• el usuario consulta una colección de grandes bases de datos y extrae información

Almacén de datos


Tarea GLOSARIO en la Plataforma Moodle

• Comercio electrónico o e-commerce

• Negocios electrónicos o E-bussines

• Intranet, internet y extranet

• Página web, Sitio web y Portal web


Atributos de CALIDAD en una WebApp

INGENIERIA WEB

UNIDAD 1


Atributos de Calidad

Todas las personas que hayan navegado alguna vez por la Web o hayan utilizado una intranet de una compañía pueden opinar sobre lo que hace una «buena» WebApp.

Los puntos de vista individuales varían enormemente.

Algunos usuarios disfrutan con gráficos llamativos, en cambio otros solo quieren un texto sencillo.

Algunos exigen información copiosa, otros desean una presentación abreviada.

En efecto, la percepción de «lo bueno» por parte del usuario (y como consecuencia, la aceptación o no aceptación resultante de la WebApp) podría ser más importante que cualquier discusión técnica sobre la calidad de la WebApp.


Pero ¿cómo se percibe la calidad de la WebApp?

¿Qué atributos deben de exhibirse ante los ojos de los usuarios para lograr lo bueno y al mismo tiempo exhibir las características técnicas de calidad que permitan a un ingeniero corregir, adaptar, mejorar y soportar la aplicación a largo plazo?


En realidad, todas las características generales de la calidad del software se aplican también a las WebApps.

Sin embargo, las características más relevantes -usabilidad, fiabilidad,

eficiencia y capacidad de mantenimiento- proporcionan una base Útil para evaluar la calidad de

los sistemas basados en Web.



Estratos de la Ingeniería Web

INGENIERIA WEB

UNIDAD 1


El desarrollo de sistemas y aplicaciones basados en Web incorpora modelos de proceso especializados, métodos de ingeniería del software adaptados a las características del desarrollo de WebApps y un conjunto de importantes tecnologías habilitadoras.


Los procesos, métodos y tecnologías (herramientas) proporcionan un enfoque en estratos de la IWEB que es conceptualmente

idéntico a los estratos de la ingeniería de software



PROCESO IWEB



Proceso de Ingeniería Web

Pressman sugiere un proceso de ingeniería web

compuesto por las siguientes fases:



Planteamiento y formulación

Identificamos los objetivos de

nuestra aplicación, y

delimitamos el alcance de la

primera iteración.



Planificación

Una vez planteado el problema,

podremos estimar costos,

riesgos

esfuerzo durante

el desarrollo

Recordemos que en la planeación

iterativa solamente se

detalla la iteración actual,

y las iteraciones

subsecuentes sólo se

plantean de forma general.



Análisis

• los requerimientos técnicos,

• gráficos,

• y de contenido,

• que incorporaremos en la iteración.

Durante esta etapa

establecemos


Análisis

Los conceptos y principios que se trataron para el análisis de los requisitos del software se aplican sin revisión en la actividad de análisis de ingeniería Web.

Para crear un modelo de análisis completo para la WebApp se elabora el ámbito definido durante la actividad de formulación.

Durante la Iweb se realizan cuatro tipos de análisis diferentes:


Análisis del contenido

Análisis de la interacción

Análisis funcional

Análisis de la configuración





Se trata de la identificación del espectro completo de

contenido que se va a

proporcionar.

En el contenido se

incluyen datos de texto, gráficos,

imágenes, vídeo y sonido.

Para identificar y

describir cada uno de los objetos de

datos que se van a utilizar dentro de la WebApp se

puede utilizar el modelado

de datos.


Análisis de la Interacción


Análisis de la interacción

Se trata de la descripción detallada de la interacción del usuario y la WebApp.

Para proporcionar descripciones detalladas de esta interacción se pueden desarrollar casos prácticos.


Análisis Funcional


Análisis funcional

Los escenarios de utilización (casos de uso) creados como parte del análisis de interacción definen las operaciones que se aplicarán en el

contenido de la WebApp e implicarán otras funciones de procesamiento.

Aquí se realiza una descripción detallada de todas las funciones y operaciones.


Análisis de la Configuración


Análisis de la configuración

Se efectúa una descripción detallada del entorno y de la infraestructura en donde reside la WebApp.

La WebApp puede residir en Internet, en una intranet o en una Extranet.

Además, se deberá identificar la infraestructura (es decir, la infraestructura de los componentes y el grado de utilización de la base de datos para generar el contenido) de la WebApp.


Aun cuando se recomienda una especificación detallada de los requisitos para WebApps grandes y complejas, tales documentos no son los usuales.

Se puede decir que la continua evolución de los requisitos de la WebApp puede hacer que cualquier documento se quede obsoleto antes de finalizarse.

Aunque se puede decir que esto sucede de verdad, es necesario definir un modelo de análisis que pueda funcionar como fundamento de la siguiente actividad de diseño.

Como mínimo, la información recogida durante las cuatro tareas de análisis anteriores deberá ser revisada, modificada a petición, y organizada para formar un documento que pueda pasarse a los diseñadores de WebApps.



Ingeniería

La actividad de ingeniería incorpora dos grupos de tareas que se realizan en paralelo:

• el diseño del contenido y la producción,

• se enfocan en el diseño, producción y adquisición del contenido de texto, gráfico y video que se vayan a integrar en la aplicación.

Estas tareas son realizadas por personal no técnico.

Por otro lado, están el diseño arquitectónico, de navegación e interfaz, el cual lidia con los aspectos técnicos.


Diseño del contenido


Diseño para aplicaciones basada en web

La naturaleza de inmediatez de las aplicaciones basadas en Web unida a la presión de evolucionar continuamente obliga a que un ingeniero establezca un diseño que resuelva el problema comercial inmediato, mientras que al mismo tiempo obliga a definir una arquitectura de aplicación que tenga la habilidad de evolucionar rápidamente con el tiempo.

El problema, desde luego, es que resolver (rápidamente) el problema inmediato puede dar como resultado compromisos que afectan a la habilidad que tiene la aplicación de evolucionar con el paso del tiempo.


Con objeto de realizar un diseño eficaz basado en Web, el ingeniero deberá trabajar reutilizando cuatro elementos técnicos:

Principios y métodos de diseño

Reglas de oro

Configuraciones de diseño

Plantillas


Principios y métodos de diseño

Es importante destacar que los conceptos y principios del diseño se aplican a todas las WebApps.

La modularidad eficaz (exhibida con una cohesión alta y con un acoplamiento bajo), la elaboración paso a paso, y cualquier otra heurística de diseño del software conducirá a sistemas y aplicaciones basados en Web más fáciles de adaptar, mejorar, probar y utilizar.


Cuando se crean aplicaciones Web se pueden reutilizar los métodos de diseño que se utilizan para los sistemas orientados a objetos.

La hipermedia define «objetos» que interactúan mediante un protocolo de comunicación algo similar a la mensajería.

De hecho, la notación de diagramas propuesta por UML puede adaptarse y utilizarse durante las actividades de diseño de las WebApps.

Además, se han propuesto otros hipermedios de métodos de diseño


Reglas de oro

Las aplicaciones hipermedia interactivas

(WebApps) llevan construyéndose ya hace una década.

Durante ese tiempo, los diseñadores han

desarrollado un conjunto de

heurísticas de diseño (reglas de

oro) que se podrán volver a aplicar

durante el diseño de aplicaciones nuevas.


Configuraciones de diseño

Las configuraciones de diseño son un enfoque genérico para resolver pequeños problemas que se pueden adaptar a una variedad más amplia de problemas específicos.

En el contexto de las WebApps, las configuraciones de diseño se pueden aplicar no solo a los elementos funcionales de una aplicación, sino también a los documentos, gráficos y estética general de un sitio Web.


Plantillas

Las plantillas se pueden utilizar para proporcionar un marco de trabajo

esquemático de cualquier configuración de diseño o

documento a utilizar dentro de una WebApp.

Nanard y Kahn describen este elemento de diseño reutilizable de la

siguiente manera:



Una vez que se ha especificado una plantilla, cualquier parte de una estructura hipermedia que se acopla a esta plantilla se podrá generar o actualizar automáticamente llamando solamente a la plantilla con datos relevantes [para dar cuerpo al esquema].

La utilización de plantillas constructivas depende implícitamente del contenido separado de los documentos hipermedia, de la especificación y de su presentación:

• los datos fuente se organizan en la estructura del hipertexto tal y como se especifica en la plantilla


Diseño Arquitectónico


Diseño arquitectónico

El diseño arquitectónico para los sistemas y aplicaciones basados en Web se centra en la definición de la estructura global hipermedia para la WebApp, y en la aplicación de las configuraciones de diseño y plantillas constructivas para popularizar la estructura (y lograr la reutilización).

Una actividad paralela, llamada diseño del contenido, deriva la estructura y el formato detallados del contenido de la información que se presentará como parte de la WebApp.


Estructuras de las WebApps

La estructura arquitectónica global va unida a las metas establecidas para una WebApp, al contenido que se va a presentar, a los usuarios que la visitarán y a la filosofía de navegación establecidos.

Cuando el encargado de la arquitectura va a realizar el diseño de una WebApp típica puede elegir entre cuatro fuentes diferentes.


Las estructuras lineales

Aparecen cuando es común la sucesión predecible de interacciones (con alguna variación o diversificación).

Un ejemplo clásico podría ser la presentación de un manual de usuario en la que las páginas de información se presentan con gráficos relacionados, vídeos cortos o sonido solo después de haber presentado un prerrequisito.

La sucesión de presentación del contenido queda predefinida y se puede decir que, generalmente, es lineal.


A medida que el contenido y el procesamiento crecen en complicación, el flujo puramente lineal que se muestra a la derecha da como resultado estructuras lineales más sofisticadas en las que se puede invocar el contenido alternativo, o en donde tiene lugar

una desviación para adquirir un contenido complementario



Las estructuras reticulares Son una opción arquitectónica que puede aplicarse cuando el contenido de la WebApp puede ser organizado categóricamente en dos dimensiones (o más).

Por ejemplo, consideremos una situación en la que un sitio de comercio electrónico vende palos de golf.

La dimensión horizontal de la retícula representa el tipo de palo en venta (por ejemplo, maderas, hierros, wedges, putters).

La dimensión vertical representa la oferta proporcionada por los fabricantes de palos de golf.


De aquí que un usuario pueda navegar por la

retícula horizontalmente para encontrar la columna de los putters, y recorrer la columna para examinar las ofertas proporcionadas por los vendedores de putters.

Esta arquitectura WebApp es de utilidad solo cuando se

encuentra un contenido muy

regular.



Las estructuras jerárquicas

Son sin duda la arquitectura WebApp más común.

A diferencia de la división de jerarquías de software, que fomentan el flujo de control solo a lo largo de las ramas verticales de la jerarquía, se podrá diseñar una estructura jerárquica de la WebApp para posibilitar (por medio de la ramificación de hipertexto) el flujo de control en horizontal atravesando las ramas verticales de la estructura.


Por tanto, el contenido presentado en la rama del extremo izquierdo de la jerarquía puede tener enlaces de hipertexto que lleven al contenido

que existe en medio de la rama derecha de la estructura.

Sin embargo, debería de destacarse que aunque dicha rama permita una navegación rápida por el contenido

de la WebApp, puede originar también confusión por parte del

usuario.



Una estructura en red o de «web pura»

se asemeja en muchos aspectos a la arquitectura en evolución para los sistemas orientados a objetos.

Los componentes arquitectónicos (en este caso las páginas Web) se diseñan de forma que pueden pasar el control (mediante enlaces de hipertexto) a otros componentes del sistema.

Este enfoque permite una flexibilidad de navegación considerable, aun cuando puede resultar confuso para el usuario.



Patrones de diseño

Los patrones de diseño son un buen método para resolver pequeños problemas que pueden adaptarse a una variedad mucho más amplia de problemas específicos.

En el contexto de los sistemas y aplicaciones basados en Web, los patrones de diseño pueden aplicarse en el nivel jerárquico, nivel de componentes y nivel de hipertexto (de navegación).


Cuando dentro de una WebApp se requiere la funcionalidad del proceso de datos, pueden aplicarse los patrones de diseños arquitectónicos a nivel de componentes.

Los patrones de diseño a nivel de hipertexto se centran en el diseño de las características de navegación que permiten al usuario moverse por el contenido de la WebApp fácilmente.

Entre muchos de los patrones de diseño de hipertexto propuestos se encuentran los siguientes:


• una configuración que devuelve al usuario al nodo de contenido visitado anteriormente. Ciclo:

• una configuración que implementa un «gran ciclo que enlaza hipertextos enteros viajando por un tema».

Anillo de Web:

• un patrón que aparece cuando varios ciclos inciden en otro, permitiendo navegar por rutas definidas por los ciclos.

Contorno:


• un patrón que añade comentarios de hipertexto interrumpiendo la narrativa del contenido para proporcionar más información o más indagación.

Contrapunto:

• el contenido se presenta utilizando diferentes hilos narrativos, cada uno con un punto de vista o perspectiva diferente. Por ejemplo, el contenido que describe una computadora personal podría permitir al usuario seleccionar una narrativa «técnica» o «no técnica» que describa la máquina.

Mundo de espejo:


• una configuración que va guiando al usuario a través de una serie de opciones (decisiones) con el fin de llevar al usuario a un contenido específico e indicado por la sucesión de opciones elegidas o decisiones tomadas.

Tamiz:

• una configuración que abarca un marco de navegación uniforme por todas las páginas Web para permitir que un usuario tenga una guía de navegación consecuente independientemente de la localización de la WebApp.

Vecindario:


Diseño de navegación


Diseño de navegación

Una vez establecida una arquitectura de WebApp, una vez identificados los componentes (páginas, guiones applets y otras funciones de proceso) de la arquitectura, el diseñador deberá definir las rutas de navegación que permitan al usuario acceder al contenido y a los servicios de la WebApp.


Para que el diseñador pueda llevarlo a cabo, debe

• (1) identificar la semántica de la navegación para diferentes usuarios del sitio; y

• (2) definir la mecánica (sintaxis) para lograr la navegación.

Generalmente una WebApp grande tendrá una variedad de roles de usuarios diferentes.


visitante, cliente registrado o cliente privilegiado.

Por ejemplo, los roles podrían ser el de

diferentes niveles de acceso al contenido y de servicios diferentes.

Cada uno de estos roles se pueden asociar a

mientras que un cliente registrado puede tener acceso a una variedad mucho más amplia de información y de servicios.

Un visitante puede tener acceso sólo a un contenido

limitado,

serían diferentes.

La semántica de la navegación de cada uno de

estos roles


El diseñador de WebApps crea una unidad semántica de navegación (USN) para cada una de las metas asociadas a cada uno de los roles de usuario.

Por ejemplo, un cliente registrado puede tener seis metas diferentes, todas ellas con un acceso a información y servicios diferentes.

Para cada meta se crea una USN.


Gnaho y Larcher describen la USN de la siguiente manera:

Eso significa que las USNs pueden agregarse para formar una USN de nivel superior,

o anidarse en cualquier nivel de profundidad.

La estructura de una WoN se compone de un conjunto de nodos de navegación (NN) relevantes conectados a enlaces de navegación,

entre los que algunas veces se incluyen las USNs.

Por tanto, el concepto de WoN se asocia al concepto de Perfil de Usuario.

Una WoN representa la mejor forma de navegación o ruta

para que usuarios con ciertos perfiles logren su meta o submeta deseada.

La estructura de una USN se compone de un conjunto de subestructuras de navegación

que llamarnos formas de navegación [WoN (Ways of navigating)].


Durante las etapas iniciales del diseño de navegación, para

determinar una o más WoNs para cada meta de usuario, se

evaluará la estructura de la WebApp (arquitectura y

componentes).

Como se ha destacado anteriormente, una WoN

identifica los nodos de navegación (por ejemplo,

páginas Web), y entonces los enlaces que hacen posible la

navegación entre ellos.

La WoN entonces se organiza en USNs


A medida que avanza el diseño, se va

identificando la mecánica de cada

enlace de navegación.

Entre otras muchas opciones se encuentran los enlaces basados en texto, iconos, botones,

interruptores y metáforas gráficas.


El diseñador deberá elegir los enlaces de navegación adecuados para el contenido y consecuentes con la heurística que conduce al diseño de una interfaz de alta calidad.

Además de elegir la mecánica de navegación, el diseñador también deberá establecer las convenciones y ayudas adecuadas.

Por ejemplo, los iconos y los enlaces gráficos deberán tener un aspecto «clickable (capacidad de accederse)» con los bordes biselados, y dar así una imagen en tres dimensiones.


La realimentación visual o de sonido se deberá

diseñar para proporcionar al usuario una indicación de que se ha elegido una

opción de navegación.

Para la navegación basada en texto, se deberá utilizar

el color que indica los enlaces de navegación y

proporcionar una indicación de los enlaces

por los que se ha navegado.

Estas son solo unas pocas convenciones de las

docenas que hacen que la navegación por la red sea

agradable.

Además de las convenciones, en este

punto también se deberán diseñar ayudas de

navegación tales como mapas de sitios, tablas de contenidos, mecanismos de búsqueda y servicios

dinámicos de ayuda


Diseño de interfaz


Diseño de interfaz

La interfaz de usuario de una WebApp es la «primera impresión». Independientemente

del valor del contenido, la sofisticación de las capacidades, los servicios de procesamiento y

el beneficio global de la WebApp en sí, una interfaz con un diseño pobre decepcionará al

usuario potencial y podrá de hecho hacer que el usuario se vaya a cualquier otro sitio.


Dado el gran volumen de WebApps que compiten

virtualmente en todas las áreas temáticas, la interfaz debe

«arrastrar» inmediatamente al usuario potencial.

Nielsen y Wagner sugieren unas cuantas líneas generales y

sencillas en el rediseño de una WebApp:


Probabilidad de que los errores del servidor, incluso los más pequeños, hagan que el usuario abandone

el sitio Web y busque información y servicios en algún otro sitio.

La velocidad de lectura del monitor de una computadora es aproximadamente un 25 por 100

más lento que leer una copia impresa.

Por tanto, no hay que obligar al usuario a leer cantidades voluminosas de texto, particularmente cuando el texto explica la operación de la WebApp

o ayuda a navegar por la red.


Evite los símbolos «bajo construcción» levantan expectación y provocan un enlace innecesario que seguramente

sea decepcionante.

Los usuarios prefieren no tener que recorrer la pantalla.

Dentro de las dimensiones normales de una ventana del navegador se deberá

incluir información importante.


Los menús de navegación y las barras de cabecera se deberán diseñar consecuentemente y deberán estar disponibles en todas las páginas a las que el usuario tenga acceso.

El diseño no deberá depender de las funciones del navegador para ayudar en la navegación.

La estética nunca deberá sustituir la funcionalidad.


Por ejemplo, un botón sencillo podría ser una opción de navegación mejor que una imagen o icono estéticamente agradables, pero vagos cuya intención no es muy clara.

Las opciones de navegación deberán ser obvias, incluso

para el usuario casual.

El usuario deberá buscar la pantalla para determinar

cómo enlazar con otro contenido o servicio.


Una interfaz bien diseñada mejora la percepción del contenido o de los servicios del usuario que proporciona el sitio Web.

No tiene que ser necesariamente deslumbrante, pero deberá estar siempre bien estructurada y ergonómica.



Generación de páginas y pruebas

Se prueba que el contenido dinámico se genere correctamente, utilizando las plantillas, interfaces y contenidos diseñados en la fase de ingeniería.

Posteriormente se realizan las pruebas pertinentes, que dependerán del tipo de aplicación y requerimientos no funcionales (por ejemplo, pruebas de desempeño, etcétera).


Pruebas de las aplicaciones

basadas en web


Pruebas de las aplicaciones basadas en web

El enfoque de las pruebas de las WebApps adopta los principios

básicos de todas las pruebas del software y aplica estrategias y tácticas que ya han sido recomendadas para

los sistemas orientados a objetos.

Este enfoque se resume en los pasos

siguientes:


El modelo de contenido de la WebApp es revisado para descubrir errores.

• Esta actividad de “prueba” se asemeja en muchos aspectos a la de un corrector ortográfico de un documento escrito.

• De hecho, un sitio Web grande tendrá la capacidad de construir un listado de los servicios de correctores profesionales para descubrir errores tipográficos, errores gramaticales, errores en la consistencia del contenido, errores en representaciones gráficas y de referencias cruzadas.


2. El modelo de diseño para la WebApp es revisado para descubrir errores de navegación.

• Los casos prácticos derivados como parte de la actividad de análisis permiten que un ingeniero Web ejercite cada escenario de utilización frente al diseño arquitectónico y de navegación.

• En esencia, estas pruebas no ejecutables ayudan a descubrir errores en la navegación (por ejemplo, un caso en donde el usuario no pueda leer un nodo de navegación).

• Además, los enlaces de navegación son revisados para asegurar su correspondencia con los especificados en cada USN del rol de usuario.


3. Se aplican pruebas de unidad a los componentes de proceso seleccionados y las páginas Web.

• Cuando lo que se tiene en consideración es el tema de las WebApps el concepto de unidad cambia.

• Cada una de las páginas Web encapsulará el contenido, los enlaces de navegación y los elementos de procesamiento (formularios, guiones, applets). No siempre es posible o práctico comprobar cada una de las características individualmente.

• En muchos casos, la unidad comprobable más pequeña es la página Web.

• A diferencia de la comprobación de unidades de software convencional, que tiende a centrarse en el detalle algorítmico de un módulo y los datos que fluyen por la interfaz del módulo, la comprobación por páginas se controla mediante el contenido, proceso y enlaces encapsulados por la página Web.


4. Se construye la arquitectura, se realizan las pruebas de integración.

• La estrategia para la prueba de integración depende de la arquitectura que se haya elegido para la WebApp.

• Si la WebApp se ha diseñado con una estructura jerárquica lineal, reticular o sencilla, es posible integrar páginas Web de una manera muy similar a como se integran los módulos del software convencional.

• Sin embargo, si se utiliza una jerarquía mezclada o una arquitectura de red (Web), la prueba de integración es similar al enfoque utilizado para los sistemas OO.

• La comprobación basada en hilos se puede utilizar para integrar un conjunto de páginas Web (se puede utilizar una USN para definir el conjunto adecuado) que se requiere para responder a un suceso de usuario.

• Cada hilo se integra y se prueba individualmente. La prueba de regresión se aplica para asegurar que no haya efectos secundarios.

• La comprobación de agrupamientos integra un conjunto de páginas colaborativas (determinadas examinando los casos prácticos y la USN).

• Los casos de prueba se derivan para descubrir errores en las colaboraciones.


5. La WebApp ensamblada se prueba para conseguir una funcionalidad global y un contenido.

• Al igual que la validación convencional, la validación de los sistemas y aplicaciones basados en Web se centra en acciones visibles del usuario y en salidas reconocibles para el usuario que procedan del sistema.

• Para ayudar en la derivación de las pruebas de validación, las pruebas deberán basarse en casos prácticos.

• El caso práctico proporciona un escenario con una probabilidad alta de descubrir errores en los requisitos de interacción del usuario


6. La WebApp se implementa en una variedad de configuraciones diferentes de entornos y comprobar así la compatibilidad con cada configuración.

• Se crea una matriz de referencias cruzadas que define todos los sistemas operativos probables, plataformas de hardware para navegadores y protocolos de comunicación.

• Entonces se llevan a cabo pruebas para descubrir los errores asociados con todas y cada una de las configuraciones posibles


7. La WebApp se comprueba con una población de usuarios finales controlada y monitorizada. Se selecciona un grupo de usuarios que abarque todos los roles posibles de usuarios.

• La WebApp se pone en práctica con estos usuarios y se evalúan los resultados de su interacción con el sistema para ver los errores de contenido y de navegación, los intereses en usabilidad, compatibilidad, fiabilidad y rendimiento de la WebApp.

• Dado que muchas WebApps están en constante evolución, el proceso de comprobación es una actividad continua, dirigida por un personal de apoyo a la Web que utiliza pruebas de regresión derivadas de pruebas desarrolladas cuando se creó la WebApp.


Problemas de gestión


Dada la inmediatez de las WebApps, sería razonable preguntarse:

¿necesito realmente invertir tiempo esforzándome con la WebApp?

¿no debería dejarse que la WebApp evolucionara de forma natural, con poca o ninguna gestión explícita?

Muchos diseñadores de Webs optarían por gestionar poco o nada, pero eso no hace que estén en lo cierto.

La ingeniería Web es una actividad técnica complicada.


Hay muchas personas implicadas, y a menudo trabajando en paralelo.

La combinación de tareas técnicas y no técnicas que deben de tener lugar (a tiempo y dentro del presupuesto) para producir una WebApp de alta calidad representa un reto para cualquier grupo de profesionales.

Con el fin de evitar cualquier confusión, frustración y fallo, se deberá poner en acción una planificación, tener en cuenta los riesgos, establecer y rastrear una planificación temporal y definir los controles.

Estas son las actividades clave que constituyen lo que se conoce como gestión de proyectos.



Evaluación del cliente

Al final de cada iteración se debe realizar una evaluación con el cliente, para validar el avance y determinar los

cambios o mejoras –en caso de ser necesarios–, que se aplicarán en las siguientes iteraciones.


No reinventar la rueda


Una regla de oro en el desarrollo de

cualquier tipo de aplicación es: “no

reinventar la rueda”.

Tal vez algo que agregaríamos al

proceso sugerido por Pressmann, sería

incorporar actividades específicas para

evaluar cuáles de los componentes que ya

existen se pueden reutilizar.


Así que antes de lanzarnos a desarrollar desde cero,

echemos un vistazo a los elementos existentes tanto dentro como fuera de nuestra organización.

Por ejemplo: prácticamente todos los websites y portales modernos

utilizan un CMS (Content Management System).

Esto es porqué en el ambiente web existen muchos frameworks y engines

que se pueden adaptar fácilmente a nuestras necesidades.

Documents

UNIDAD 1 Fundamentos de La IWeb