Ingeniería Web

 Los atributos de aplicaciones basadas en web

Los sistemas y las aplicaciones' basados en Web (nos referiremos a estas como WebApps) son muy diferentes de las otras categorías de software informático

Powell resume las diferencias básicas cuando afirma que los sistemas basados en Web implican una mezcla de publicación impresa y desarrollo de software, de marketing e informática, de comunicaciones internas y relaciones externas, y de arte y tecnología. Los atributos siguientes se van a encontrar en la gran mayoría de las WebApps:

Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puede residir en Internet (Haciendo posible así una comunicación abierta par todo el mundo). De forma alternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación a través de redes de una organización) o una Extranet (comunicación entre redes).

Controlada por el contenido. En muchos casos, la función primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, gráficos, sonido y vídeo.

Evolución continúa. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están en constante evolución. No es inusual que algunas WebApps (específicamente, su contenido) se actualicen cada hora.

Las siguientes características de WebApps son las que conducen el proceso:

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez que no se encuentra en otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Web completo puede ser cuestión de días o semanas3. Los desarrolladores deberán utilizar los métodos de planificación, análisis, diseño, implementación y comprobación que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.

Seguridad. Dado que las WebApps están disponibles a través de1 acceso por red, es difícil, si no imposible, limitar la población de usuarios finales que pueden acceder a la aplicación. Con objeto de proteger el contenido confidencial y de proporcionar formas seguras de transmisión de datos, deberán implementarse fuertes medidas de seguridad en toda la infraestructura que apoya una WebApp y dentro de la misma aplicación.

Estética. Una parte innegable del atractivo de una WebApp es su apariencia e interacción. Cuando se ha diseñado una aplicación con el fin de comercializarse o vender productos o ideas, la estética puede tener mucho que ver con el éxito del diseño técnico. Las características generales destacadas anteriormente se aplican a todas las WebApps, pero con un grado diferente de influencia. Las categorías de aplicaciones que se enumeran a continuación son las más frecuentes en el trabajo de la Web:

Informativa: se proporciona un contenido solo de lectura con navegación y enlaces simples.

Descarga: un usuario descarga la información desde el servidor apropiado.

Personalizable: el usuario personaliza el contenido a sus necesidades específicas.

Interacción: la comunicación entre una comunidad de usuarios ocurre mediante un espacio chat (charla), tablones de anuncios o mensajería instantánea.

Entrada del usuario: la entrada basada en formularios es el mecanismo primario de la necesidad de comunicación.

Orientada a transacciones: el usuario hace una solicitud (por ejemplo, la realización un pedido) que es cumplimentado por la WebApp.

Orientado a servicios: la aplicación proporciona un servicio al usuario, por ejemplo, ayuda al usuario a determinar un pago de hipoteca.

Portal: la aplicación canaliza al usuario llevándolo a otros contenidos o servicios Web fuera del dominio de la aplicación del portal.

Acceso a bases de datos: el usuario consulta en una base de datos grande y extrae información.

Almacenes de datos: el usuario hace una consulta en una colección de bases de datos grande y extrae información.

Las características y las categorías destacadas anteriormente en esta sección, y las categorías de aplicaciones representan los hechos reales para los ingenieros de la Web. La clave es vivir dentro de las restricciones impuestas por las características anteriores y aun así tener éxito en la elaboración de la WebApp.

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

En realidad, todas las características generales de la calidad del software. 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.

Olsina y sus colaboradores han preparado un “árbol de requisitos de calidad”  que identifica un conjunto de atributos que conduce a WebApps de alta calidad.

Las tecnologías

El diseño y la implementación de sistemas basados en Web incorporan tres tecnologías importantes: el desarrollo basado en componentes, la seguridad y los estándares de Internet. Un ingeniero Web deberá estar familiarizado con las tres para construir WebApps de alta calidad.

Desarrollo basado en componentes

Las tecnologías de componentes estudiadas  han evolucionado en gran parte gracias al crecimiento explosivo de los sistemas y aplicaciones basados en Web. Retomando el estudio del capítulo anterior, los ingenieros Web disponen de tres estándares importantes para la infraestructura: CORBA, COMDCOM y JavaBeans. Estos estándares (acompañados por los componentes pre construidos, herramientas y técnicas) proporcionan una infraestructura que permite a los que diseñan emplear y personalizar componentes de terceras partes permitiéndoles así comunicarse unos con otros y con servicios a nivel de sistemas.

Seguridad

Si en una red reside una WebApp, ésta está abierta a un acceso sin autorización. En algunos casos, ha sido el personal interno el que ha intentado acceder sin autorización. En otros casos, intrusos (hackers) pueden intentar acceder por deporte, por sacar provecho o con intenciones más maliciosas. Mediante la infraestructura de red se proporciona una variedad de medidas de seguridad, tales como encriptación, cortafuegos y otras.

Estándares de Internet

Durante la última década el estándar dominante en la creación del contenido y la estructura de la WebApp ha sido HTML, un lenguaje de marcas que posibilita al desarrollador proporcionar una serie de etiquetas que describen una gran variedad de objetos de datos (texto, gráficos, audio/vídeo, formularios, etc.). Sin embargo, a medida que las aplicaciones crecen en tamaño y complejidad, se ha adoptado un nuevo estándar –XML para la próxima generación de WebApps. XML (Extensible Markup Language) el Lenguaje de marcas extensible es un subconjunto estrictamente definido del metalenguaje SGML [BRA97], permitiendo que los diseñadores definan etiquetas personalizadas en las descripciones de una página Web. Mediante una descripción del metalenguaje XML, el significado de las etiquetas personalizadas se define en la información transmitida al sitio del cliente.

El proceso de Ing. Web

Las características de sistemas y aplicaciones basados en web influyen enormemente en el proceso de Ingeniería Web. La inmediatez y la evolución continúan dictando un modelo9 de proceso incremental e interactivo que elabora versiones de WebApps muy rápidamente. La naturaleza intensiva de red de las aplicaciones en este dominio sugiere una población de usuarios diversa (exigiendo especialmente la obtención y modelado de requisitos), y una arquitectura de aplicación  que puede ser alternante especializada (realizando de esta manera exigencias en el diseño) Dado que la WebApps  suelen ser controladas por el contenido haciendo hincapié en la estética, es probable que las actividades de desarrollo paralelas se planifiquen dentro del proceso Ing. Web y necesiten un equipo técnicas y no técnicas.

 

Diseño para aplicaciones basadas en web

Principios y métodos de diseño.

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.

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. Como se ha destacado anteriormente en este libro, 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.

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

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 contenido6, deriva la estructura y el formato detallados del contenido de la información que se presentará como parte de la WebApp.

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 (Sección 29.5.3) 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 (Fig. 29.3) 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. Otro ejemplo podría ser la sucesión de una entrada de pedido de un producto donde se tenga que especificar la información específica en un orden específico. En tales casos, las estructuras que se muestran en la Figura 29.3 son las adecuadas. 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.

Las estructuras arquitectónicas estudiadas en los párrafos anteriores se pueden combinar para formar estructuras compuestas. La arquitectura global de una WebApp puede ser jerárquica, pero parte de la estructura puede exhibir características lineales, mientras que otra parte de la arquitectura puede confeccionarse en red. La meta del diseñador arquitectónico es hacer corresponder la estructura de la WebApp con el contenido que se va a presentar y con el procesamiento que se va a llevar a cabo.

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)

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

Anillo de Web: una configuración que implementa un «gran ciclo que enlaza hipertextos enteros viajando por un tema».

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

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

Mundo de espejo: 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.

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

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

Las configuraciones de diseño de hipertexto que se han descrito anteriormente se pueden recalzar a medida que el contenido va adquiriendo el formato que permitirá la navegación a través de una WebApp.

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. Por ejemplo, los roles podrían ser el de visitante, cliente registrado o cliente privilegiado. Cada uno de estos roles se pueden asociar a diferentes niveles de acceso al contenido y de servicios diferentes. Un visitante puede tener acceso sólo a un contenido limitado, mientras que un cliente registrado puede tener acceso a una variedad mucho más amplia de información y de servicios. La semántica de la navegación de cada uno de estos roles sería diferente. 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:

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). Una WoN representa la mejor forma de navegación o ruta para que usuarios con ciertos perfiles logren su meta o submeta deseada. Por tanto, el concepto de WoN se asocia al concepto de Perfil de Usuario. 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. Eso significa que las USNs pueden agregarse para formar una USN de nivel superior, o anidarse en cualquier nivel de profundidad

Diseño de la 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 toda el área temática, 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.

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.