Ingenieria Web

A.   Los atributos de aplicaciones basados en web

No hay mucho que decir con respecto al hecho de que 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 WebApps2:

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 para 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. Algunos argumentan que la evolución continua de las WebApps hace que el trabajo realizado en ellas sea similar a la jardinería. Lowe trata este tema con el siguiente escrito:

La ingeniería está a punto de adoptar un enfoque científico y consecuente, suavizado por un contexto específico y práctico, para el desarrollo y el comisionado de sistemas y aplicaciones. El desarrollo de los sitios Web suele estar destinado a crear una infraestructura (sembrar el jardín) y entonces «ocuparse» de la información que crece y brota dentro del jardín. Después de un tiempo, el jardín (es decir, el sitio Web) continuará evolucionando, cambiando y creciendo. Una buena arquitectura inicial deberá permitir que este crecimiento ocurra de forma controlada y consecuente.. .podemos hacer que «tres cirujanos» podaran los «árboles» (es decir, las secciones del sitio Web) dentro del jardín (el sitio en sí) a la vez se asegura la integridad de las referencias cruzadas. Podríamos disfrutar de «guarderías de jardín» donde «se cultiven)) las plantas jóvenes (es decir, las configuraciones de diseño para sitios Web). Acabemos con esta analogía, no vaya a ser que vayamos demasiado lejos.

Un cuidado y una alimentación continua permiten que un sitio Web crezca (en robustez y en importancia). Pero a diferencia de un jardín, las aplicaciones Web deben de servir (y adaptarse a) las necesidades de más de un jardinero, Las siguientes características de WebApps son las que conducen el proceso:

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez [NOR99] 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 semanas. 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 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 estudiadas 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. 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. La Figura 29.1 resume su trabajo.

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 predeterminados, 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. Un estudio amplio de este tema queda fuera del ámbito de este libro.

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

1. El proceso de IWeb

Las características de sistema y aplicaciones basadas en WEB influyen enormemente en el proceso de IWeb. La inmediatez y la evolución continúan dictando un modelo 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 pueda ser altamente especializada (realizando de esta manera exigencias en el diseño). Dado que las 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 Iweb y necesitan un equipo de personas tanto técnicas como no (por ejemplo, redactores publicitarios, diseñadores gráficos).

2. Un marco de trabajo para la Iweb

A medida que la evolución de las WebApps para de utilizar recursos estáticos de información controlada para el contenido a utilizar entornos de aplicaciones dinámicos controlados por el usuario, cada vez es más importante la necesidad de aplicar una gestión solida y unos principios de ingeniería. Para conseguir esto, es necesario desarrollar un marco de trabajo Iweb que acompañe a un modelo de proceso eficaz , popularizado por las actividades del marco de trabajo y por las tareas de ingeniería. En la figura 29.2 se sugiere un modelo de proceso para Iweb.

El proceso Iweb comienza con la formulación, actividad que identifica las metas y los objetivos de la WebApp y establece el ámbito del primer incremento.

La planificación estima el coste global del proyecto, evalua los riesgos asociados con el esfuerzo del desarrollo, y define una planificación de desarrollo bien granulada para el incremento final de la WebApp, con una planificación mas toscamente granulada para los incrementos sudsiguientes. El análisis establece los requisitos técnicos para la WebApp e identifica los elementos del contenido que se va a incorporar. También se definen los requisitos del diseño grafico (estética).

La actividad de ingeniería incorpora 2 tareas paralelas, como se muestra en la figura 29.2. el  diseño de contenido  y la producción  son tareas llevadas a cabo personas no técnicas del equipo Iweb. El objetivo de estas tareas diseñar, producir y/o adquirir todo el contenido de texto, grafico y video que se vayan a integrar a la WebApp. Al mismo tiempo se lleva a cobo un conjunto de tareas de  diseño.

La generación de páginas es una actividad de construcción que hace mucho uso de las herramientas automatizadas para la creación de la WebApp. El contenido definido de las actividades de ingeniería se fusiona con los diseños arquitectónicos, de navegación y de la interfaz para elaborar páginas web ejecutables en HTML, XML y otros lenguajes orientados a procesos (por ejemplo, Java). Durante las actividades también se lleva a cabo la integración con el software intermedio (middleware) de componentes (es decir, COBRA, DCOM o JavaBeans). Las pruebas ejercitan la navegación, intentan descubrir los errores de las applets, guiones y formularios, y ayuda a asegurar que la WebApp funcionara correctamente en diferentes entornos.  

Cada incremento producido como parte del proceso Iweb se revisa durante la actividad de evaluación del cliente. Este es un punto donde se solicitan cambios. Estos cambios se integran en la siguiente ruta de flujo incremental del proceso.

1. Formulación y análisis del sistema basado en Web

La formulación y el análisis de sistemas y aplicaciones basado en Web representan una sucesión de actividades de ingeniería Web que comienza con la identificación de metas globales para la WebApp, y termina con el desarrollo de un modelo de análisis o especificación de los requisitos para el sistema. La formulación permite que el cliente o diseñador establezca un conjunto común de metas y objetivos para la construcción de la WebApp. También identifica el ámbito de esfuerzo en el desarrollo y proporciona un medio para determinar un resultado satisfactorio. El análisis es una actividad técnica que identifica los datos y requisitos funcionales y de comportamiento para la WebApp.

 

Formulación

Powell sugiere una serie de preguntas que deberán formularse y responderse al comienzo de la etapa de formulación:

• ¿Cuál es la motivación principal para la WebApp?
• ¿Por qué es necesaria la WebApp?
• ¿Quién va a utilizar la WebApp?

La respuesta a estas preguntas deberá ser de lo más sucinto posible. Por ejemplo, supongamos que el fabricante de sistemas de seguridad en el hogar ha decidido establecer un sitio Web de comercio electrónico para vender sus productos directamente a los consumidores. Una frase que describiera la motivación de la WebApp podría ser la siguiente:

HogarSeguroInc.com5 permitirá a los consumidores configurar y comprar todos los componentes necesarios para instalar un sistema de seguridad en casa o en su comercio.

Es importante destacar que en esta frase no se ha proporcionado ningún detalle. El objetivo es delimitar la intención global del sitio Web. Después de discutir con otros propietarios de Hogar Seguro Inc., la segunda pregunta se podría contestar de la siguiente manera:

HogarSeguroInc.com nos permitirá vender directamente a los consumidores, eliminando por tanto los costes de intermediarios, y mejorando de esta manera los márgenes de beneficios. También nos permitirá aumentar las ventas en un 25 por 100 por encima de las ventas anuales y nos permitirá penetrar en zonas geográficas en donde actualmente no tenemos almacenes de ventas.

Finalmente, la compañía define la demografía para la WebApp: «Los usuarios potenciales de HogarSeguroInc.com son propietarios de casas y de negocios pequeños.» Las respuestas que se han establecido anteriormente implican metas específicas para el sitio Web Hogar-SeguroInc.com. En general, se identifican dos categorías:

• Metas informativas: indican la intención de proporcionar el contenido y/o información específicos para el usuario final.
• Metas aplicables: indican la habilidad de realizar algunas tareas dentro de la WebApp.

En el contenido de la Web HogarSeguroInc.com, una meta informativa podría ser la siguiente: El sitio proporcionará a los usuarios especificaciones de un producto detallado, como descripción técnica, instrucciones de instalación e información de precios. El examen de las respuestas anteriores llevará a HogarSeguroInc.com consultará al cliente sobre la instalación (es decir, sobre la casa, oficina/almacén minorista) que se va a proteger, y dará recomendaciones personalizadas sobre el producto y la configuración que se va utilizar.

Una vez que han identificado todas las metas aplicables e informativas se desarrolla el perfil del cliente. El perfil del usuario recoge «las características relevantes de los usuarios potenciales incluyendo antecedentes, conocimiento, preferencias e incluso más». En el caso de HogarSeguroInc.com, el perfil de usuario identificará las características de un comprador típico de sistemas de seguridad (esta información sería proporcionada por el departamento de marketing de HogarSeguroInc.com).

Una vez que se han desarrollado las metas y los perfiles de usuarios, la actividad de formulación se centra en la afirmación del ámbito para la WebApp.

En muchos casos, las metas ya desarrolladas se integran en la afirmación del ámbito. Además es Útil, no obstante, indicar el grado de integración que se espera para la WebApp. Es decir, a menudo es necesario integrar los sistemas de información existentes (por ejemplo, la aplicación de base de datos existente) en un planteamiento basado en Web. En este punto se tienen en consideración también los temas de conectividad.

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

2. 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 define 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. 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 estudiados anteriormente en este libro. 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 (por ejemplo, [ISA95], [SCH96]).

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

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.

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 (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 (la estructura se muestra a la derecha en la Fig. 29.3).

Las estructuras reticulares (Fig. 29.4) 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 (Fig. 29.5) 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» (Fig. 29.6) 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

Como se ha destacado anteriormente en este mismo libro, 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 propuestas por [BUS96], [GAM95] y otros. 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 en literatura sobre este tema se encuentran los siguientes:

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

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 la interfaz

Los conceptos, principios y métodos de diseños de interfaz que se presentaron en el Capítulo 15 son todos aplicables al diseño de interfaces de usuario para WebApps. Sin embargo, las características especiales de los sistemas y aplicaciones Web requieren otras consideraciones adicionales.

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. Un estudio completo de las interfaces WebApp de usuario está fuera del ámbito de este libro.

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

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

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

El equipo de IWEB

La creación de una buena aplicación Web exige un amplio abanico de conocimientos. Tilley y Huang se enfrentan a este tema cuando afirman: «Hay muchos aspectos diferentes en relación con el software de aplicaciones [Web] debido al resurgimiento del renacentista, aquel que se encuentra cómodo trabajando en varias disciplinas.. .» Aun cuando los autores están absolutamente en lo cierto, los «renacentistas» no disponen de muchas provisiones, y dado las exigencias asociadas a los proyectos importantes de desarrollo de WebApps, el conjunto de conocimientos diversos necesario podrá distribuirse incluso mejor dentro del equipo de IWeb.

Los equipos de IWeb pueden organizarse de forma muy similar a como se organizan los equipos de software. Sin embargo, pueden existir diferencias entre los participantes y sus roles. Entre los muchos conocimientos que deben distribuirse por los miembros del equipo IWeb se encuentran los siguientes: ingeniería del software basada en componentes, realización de redes, diseño arquitectónico y de navegación, lenguajes y estándares de Internet, diseño de interfaces para personas, diseño gráfico, disposición del contenido y pruebas de las WebApps. Los roles' siguientes deberán ser distribuidos entre los miembros del equipo IWeb:

Desarrolladores y proveedores de contenido. Dado que las WebApps son controladas inherentemente por el contenido, el papel de los miembros del equipo IWeb se centra en la generación y/o recolección del contenido. Retomando la idea de que el contenido abarca un amplio abanico de objetos de datos, los diseñadores y proveedores del contenido pueden proceder de diversos planos de fondo (no de software). Por ejemplo, el personal de ventas o de marketing puede proporcionar información de productos e imágenes gráficas: los productores de medios pueden proporcionar imagen y sonido; los diseñadores gráficos pueden proporcionar diseños para composiciones gráficas y contenidos estéticos; los redactores publicitarios pueden proporcionar contenido basado en texto. Además, existe la posibilidad de necesitar personal de investigación que encuentre y dé formato al contenido externo y lo ubique y referencie dentro de la WebApp.

Editores de Web. El contenido tan diverso generado por los desarrolladores y proveedores de contenido deberá organizarse e incluirse dentro de la WebApp. Además, alguien deberá actuar como conexión entre el personal técnico que diseña la WebApp y los diseñadores y proveedores del contenido. Esta función la lleva a cabo el editor de Web, quien deberá entender la tecnología tanto del contenido como de la WebApp en donde se incluye el lenguaje HTML (o ampliaciones de generaciones posteriores, tal como XML), la funcionalidad de bases de datos y guiones, y la navegación global del sitio Web.

Ingeniero de Web. Un ingeniero Web cada vez se involucra más con la gran cantidad de actividades del desarrollo de una WebApp entre las que se incluyen la obtención de requisitos, modelado de análisis, diseño arquitectónico, de navegación y de interfaces, implementación de la WebApp y pruebas. El ingeniero de Web también deberá conocer a fondo las tecnologías de componentes, las arquitecturas cliente/servidor, HTML/XML, y las tecnologías de bases de datos; y deberá tener conocimiento del trabajo con conceptos de multimedia, plataformas de hardware/software, seguridad de redes y temas de soporte a los sitios Web.

Especialistas de soporte. Este papel se asigna a la persona (personas) que tiene la responsabilidad de continuar dando soporte a la WebApp. Dado que las WebApps están en constante evolución, el especialista de soporte es el responsable de las correcciones, adaptaciones y mejoras del sitio Web, donde se incluyen actualizaciones del contenido, implementación de productos y formularios nuevos, y cambios del patrón de navegación.

Administrador. Se suele llamar Web master, y es el responsable del funcionamiento diario de la WebApp, en donde se incluye:

• El desarrollo e implementación de normas para el funcionamiento de la WebApp.
• El establecimiento de los procedimientos de soporte y realimentación.
• Los derechos de acceso y seguridad de la implementación.
• La medición y análisis del tráfico del sitio Web.
• La coordinación de los procedimientos de control de cambios.
• La coordinación con especialistas de soporte.

El administrador también puede estar involucrado en las actividades técnicas realizadas por los ingenieros de Web y por los especialistas de soporte.

Gestión del proyecto

En la Parte Segunda de este libro se tuvieron en consideración todas y cada una de las actividades globalmente llamadas gestión de proyectos'. Las métricas de procesos y proyectos, la planificación de proyectos (y estimación), el análisis y gestión de riesgos, la planificación temporal y el rastreo, SQA y CGS, se estudiaron en detalle. Se aplican a los proyectos de IWeb. Pero en la práctica, el enfoque de IWeb para la gestión de proyectos es considerablemente diferente.

En primer lugar, se subcontrata un porcentaje sustancial de WebApps a proveedores que (supuestamente) son especialistas en el desarrollo de sistemas y aplicaciones basados en Web. En tales casos, un negocio (el cliente) solicita un precio fijo para el desarrollo de una WebApp a uno o más proveedores, evalúa los precios de los candidatos y selecciona un proveedor para hacer el trabajo. Pero, ¿qué es lo que busca la organización contratista?, ¿cómo se determina la competencia de un proveedor de WebApps?, ¿cómo se puede saber si un precio es razonable?, ¿qué grado de planificación, programación temporal, y valoración de riesgos se puede esperar a medida que una organización (y su subcontratista) se va embarcando en un desarrollo importante de WebApps?

En segundo lugar, el desarrollo de WebApps es una área de aplicación relativamente nueva por tanto se pueden utilizar pocos datos para la estimación. Hasta la fecha, no se ha publicado virtualmente ninguna métrica de IWeb. De hecho, tampoco han surgido muchos estudios sobre lo que esas métricas podrían ser. Por tanto, la estimación es puramente cualitativa basada en experiencias anteriores con proyectos similares-. Pero casi todas las WebApps tienen que ser innovadoras ofreciendo algo nuevo y diferente a aquellos que la utilizan. De aquí que la estimación experimental, aunque sea Útil, está abierta a errores considerables. Por consiguiente, ¿cómo se derivan estimaciones fiables?, ¿con qué grado de seguridad pueden cumplirse los programas temporales definidos?

En tercer lugar, el análisis de riesgos y la programación temporal se predican bajo un entendimiento claro del ámbito del proyecto. Y sin embargo, la característica de «evolución continua»  sugiere que el ámbito de la WebApp sea fluido. ¿Cómo pueden controlar los costes la organización contratista y el proveedor subcontratado?, y ¿cómo pueden planificar el momento en que es probable que los requisitos cambien drásticamente a lo largo del proyecto?, ¿cómo se puede controlar el cambio del ámbito?, y lo que es más importante, dado su naturaleza ¿deberán controlarse los sistemas y aplicaciones basados en Web ?

Llegado a este punto de gestión de proyectos para WebApps, las preguntas que se han formulado por las diferencias destacadas anteriormente no son fáciles de responder. Sin embargo, merece la pena tener en consideración una serie de líneas generales.

Inicio de un proyecto. Aun cuando la subcontratación sea la estrategia elegida para el desarrollo de WebApps, una organización deberá realizar una serie de tareas antes de buscar el proveedor de subcontratación para hacer el trabajo.

1. Muchas de las actividades de análisis se deberán realizar internamente. Se identifica el público de la WebApp; se confecciona un listado de aquellos con intereses internos en la WebApp; y se definen y revisan las metas globales de la WebApp; se especifica tanto la información como los servicios que se van a proporcionar en la WebApp; se destacan los sitios Web rivales, y se definen las «medidas» cuantitativas y cualitativas para obtener una WebApp con éxito. Esta información deberá de documentarse en una especificación del producto.

2. Se deberá desarrollar internamente un diseño aproximado de la WebApp. Obviamente una persona experta en el desarrollo de WebApps creará un diseño completo, pero puede ahorrar tiempo y dinero identificando el aspecto e interacción general de la WebApp para el proveedor de subcontratación (esto siempre puede modificarse durante las etapas preliminares del proyecto). El diseño deberá incluir la indicación del proceso interactivo que se va a llevar a cabo (por ejemplo, formularios, entrada de pedidos).

3. Se deberá desarrollar una planificación temporal aproximada del proyecto, incluyendo no solo las fechas finales de entrega, sino también las fechas hito (significativas). Los hitos deberán adjuntarse a las versiones de entrega posibles a medida que avanza el proyecto.

4. Se deberá identificar el grado de supervisión e interacción del contratista con el proveedor. Deberá incluirse el nombre del contacto del proveedor y la identificación de la responsabilidad y autoridad del contacto, la definición de los puntos de revisión de calidad a medida que el desarrollo va avanzando, y la responsabilidad de los proveedores en relación con la comunicación entre organizaciones.

Toda la información desarrollada en los pasos anteriores deberá de organizarse en una solicitud de opciones que se transmite a los proveedores candidatos.

Selección entre los proveedores de subcontratación candidatos. En los últimos años han surgido miles de compañías de «diseño Web» para ayudar a las empresas a establecer una presencia y/o implicación Web en el comercio electrónico. Muchas han llegado a tener adicción por el proceso IWeb, mientras que otras muchas se asemejan a los intrusos informáticos (hackers). Con objeto de seleccionar el desarrollador de Web candidato, el contratista deberá llevar a cabo una diligencia obligada: (1) entrevistar a los clientes antiguos para determinar la profesionalidad del proveedor de Web, la habilidad de cumplir los compromisos de horarios y costes, y la habilidad de comunicarse eficazmente; (2) determinar el nombre del ingeniero jefe de Web del proveedor de proyectos anterior con éxito (y después cerciorarse de que esta persona se vea obligada mediante contrato a su implicación en el proyecto), y (3) examinar cuidadosamente las muestras de trabajo del proveedor similares en aspecto e interacción (y en área de negocios) a la WebApp que se va a contratar. Antes incluso de que se vaya a establecer la oferta, una reunión cara a cara puede proporcionar una buena impresión para que el contratista y el proveedor conecten bien.

Evaluación de la validez de las ofertas de precios y de la fiabilidad de las estimaciones. Dado que existen muy pocos datos históricos y el ámbito de las

WebApps es notoriamente fluido, la estimación es inherentemente arriesgada. Por esta razón algunos proveedores incorporarán márgenes sustanciales de seguridad en las ofertas de precios de un proyecto. Evidentemente esto es comprensible y adecuado. La pregunta no es si tenemos la mejor solución para nuestra inversión, sino la serie de preguntas que se muestran a continuación: ¿Es el coste acordado una buena oferta para proporcionar un beneficio directo o indirecto sobre la inversión y justificar así el proyecto? ¿Es el proveedor de la oferta una muestra clara de la profesionalidad y experiencia requeridas? Si la respuesta es «sí», el precio ofertado es justo.

El grado de gestión del proyecto que se puede esperar o realizar. La formalidad asociada con las tareas de gestión del proyecto (llevadas a cabo tanto por el proveedor como por el contratista) es directamente proporcional al tamaño, coste y complejidad de la WebApp. Para proyectos complejos y grandes deberá desarrollarse una planificación que defina las tareas del trabajo, los puntos de comprobación, los productos de trabajo de ingeniería, los puntos de revisión del cliente y los hitos importantes. El proveedor y el contratista deberán evaluar el riesgo en conjunto, y desarrollar los planes de mitigar, monitorizar y gestionar esos riesgos considerados como importantes. Los mecanismos para la seguridad de calidad y el control de cambios se deberán definir explícitamente al escribirse. Y tendrán que establecerse métodos de comunicación entre el contratista y el proveedor.

Evaluación de la planificación temporal del desarrollo. Dado que las planificaciones de desarrollo de las WebApps abarcan un período de tiempo relativamente corto (normalmente menos de un mes o dos), la planificación de desarrollo deberá tener un alto grado de granularidad. Es decir, las tareas del trabajo y los hitos menores se tendrán que planificar día a día. Esta granularidad permite que el contratista y el proveedor reconozcan la reducción del tiempo de planificación antes de que amenace la fecha de finalización.

Gestión del ámbito. Dado que es muy probable que el ámbito cambie a medida que avanza el proyecto de la WebApp, el modelo de proceso deberá ser incremental. Esto permite que el equipo de desarrollo «congele» el ámbito para poder crear una nueva versión operativa de la WebApp. El incremento siguiente puede afrontar los cambios de ámbito sugeridos por una revisión del incremento precedente, pero una vez que comienza el incremento, el ámbito se congela de nuevo «temporalmente». Este enfoque hace posible que el equipo de la WebApp trabaje sin tener que aceptar una corriente continua de cambios, pero reconociendo la característica de evolución continúa de la mayoría de las WebApps. Las líneas generales sugeridas anteriormente no pretenden ser un recetario a prueba de tontos para WebApps puntuales y con una producción a un coste bajo. Sin embargo, ayudarán tanto al contratista como al proveedor a iniciar el trabajo suavemente con unos conocimientos mínimos.

Problemas GCS para la IWEb

Durante la última década, las WebApps han evolucionado y han pasado de utilizar dispositivos informales para la difusión de información a utilizar sitios sofisticados para el comercio electrónico. A medida que las WebApps van creciendo en importancia para la supervivencia y el crecimiento de los negocios, también crece el control de la configuración. ¿Por qué? Porque sin controles eficaces cualquier cambio inadecuado en una WebApp (recordemos que la inmediatez y la evolución continua son los atributos dominantes de muchas WebApps) puede conducir a: (1) una ubicación no autorizada de la información del producto nuevo; (2) una funcionalidad errónea y pobremente comprobada que frustra a los visitantes del sitio Web; (3) agujeros de seguridad que ponen en peligro a los sistemas internos de las compañías, y otras consecuencias económicamente desagradables e incluso desastrosas.

Se pueden aplicar las estrategias generales para la gestión de la configuración del software (GCS), pero las tácticas y herramientas deberán adaptarse y ajustarse a la naturaleza única de las WebApps. Cuando se desarrollan tácticas para la gestión de configuración de las WebApps, deberán tenerse en consideración cuatro temas: el contenido, las personas, la escalabilidad y la política.

Contenido. Una WebApp normal contiene una gran cantidad de contenido -texto, gráficos, applets, guiones, archivos de sonido y vídeo, elementos activos de páginas, tablas, corrientes de datos y muchos más-. El reto es organizar este mar de contenido en un conjunto razonable de objetos de configuración  y entonces establecer los mecanismos de control de configuración adecuados para estos objetos. Un enfoque será modelar el contenido de la WebApp mediante la utilización de técnicas convencionales de modelado de datos, adjuntando un conjunto de propiedades especializadas a cada objeto. La naturaleza estática y dinámica de cada objeto y la longevidad proyectada (por ejemplo, existencia temporal y fija, o un objeto permanente) son ejemplos de las propiedades necesarias para establecer un enfoque GCS eficaz. Por ejemplo, si se cambia un objeto de contenido cada hora, se dice que tiene una longevidad temporal. Los mecanismos de control de este objeto serán diferentes (menos formales) de los que se aplican ya un componente de formularios (objeto permanente).

Personas. Dado que un porcentaje significativo del desarrollo de las WebApps continúa realizándose dependiendo del caso, cualquier persona que esté implicada en la WebApp puede (y a menudo lo hace) crear el contenido. Muchos creadores de contenido no tienen antecedentes en ingeniería del software y no tienen ningún conocimiento de la necesidad de una gestión de configuración. La aplicación crece y cambia de forma incontrolada.

Escalabilidad. Las técnicas y controles aplicados a una WebApp pequeña no tienen buena escalabilidad. No es muy común que una WebApp sencilla crezca significativamente cuando se implementan las interconexiones que existen dentro de los sistemas de información, bases de datos, almacenes de datos y pasarelas de portales. A medida que crece el tamaño y la complejidad, los pequeños cambios pueden tener efectos inalcanzables y no intencionados que pueden ser problemáticos. Por tanto, el rigor de los mecanismos de control de la configuración deberá ser directamente proporcional a la escalabilidad de la aplicación.

Política. ¿Quién es el propietario de una WebApp? Esta pregunta se argumenta en compañías grandes y pequeñas, y la respuesta tiene un impacto significativo en las actividades de gestión y control asociadas con la IWeb. En algunos casos los diseñadores de WebApps se encuentran fuera de la organización TI, dificultando posiblemente la comunicación. Para ayudar a entender la política asociada a IWeb, Dart sugiere las siguientes preguntas: ¿quién asume la responsabilidad de la información en el sitio Web? ¿quién asegura que los procesos de control de calidad se han llevado a cabo antes de publicar la información en el sitio Web? ¿quién es el responsable de hacer los cambios? ¿quién asume el coste del cambio? Las respuestas ayudarán a determinar qué personas dentro de la organización deberán adoptar un proceso de gestión de configuración para las WebApps.

La gestión de configuración para la IWeb está todavía en su infancia. Un proceso convencional de GCS puede resultar demasiado pesado y torpe. La gran mayoría de las herramientas GCS no tienen las características que permiten adaptarse fácilmente a la IWeb. Entre los temas que quedan por tratar se encuentran los siguientes: creación de un proceso de gestión de configuración que sea lo suficientemente hábil como para aceptar la inmediatez y la evolución continua de las WebApps; aplicación de mejores conceptos y herramientas de gestión de configuración para aquellos que desarrollan y no están familiarizados con la tecnología; suministro del soporte a los equipos de desarrollo de WebApps distribuidos; suministro de control en un entorno de publicación, donde el contenido cambia de forma casi continua; consecución de la granularidad necesaria para controlar una gran cantidad de objetos de configuración; incorporación de la funcionalidad de gestión de configuración en las herramientas IWeb existentes; gestión de cambios en objetos que contienen enlaces con otros objetos. Estos y otros temas deberán afrontarse antes de que se disponga una gestión de configuración eficaz para la Iweb.

Bibliografía:

Pressman .S. Roger. Ingeniería de Software. Un enfoque practico. Editorial McGraw-Hill V Edición. Pág. 521-537