INGENIERÍA WEB - Informática Coacalco · cando las mismas prácticas SQA ... plinada y de...

CAPÍTULO

29 INGENIERÍA WEB

A World Wide Web e Internet han introducido a la población en general en el mundo de la informática. Compramos fondos de inversión colectivos y acciones, descargamos L música, vemos películas, obtenemos asesoramiento médico, hacemos reservas de habi-

taciones en hoteles, vendemos artículos personales, planificamos vuelos en líneas aéreas, cono- cemos gente, hacemos gestiones bancarias, recibimos cursos universitarios, hacemos la compra -es decir, en el mundo virtual se puede hacer todo lo que se necesite-. Se puede decir que Internet y la Web son los avances más importantes en la historia de la informática. Estas tec- nologías informáticas nos han llevado a todos nosotros a la era de la informática (con otros millones de personas quienes finalmente entrarán también). Durante los primeros años del siglo veintiuno estas tecnologías han llegado casi a formar parte de nuestra vida diaria.

Para todos nosotros que recordamos un mundo sin Web, el crecimiento caótico de la tecno- logía tiene su origen en otra era -los primeros días del software-. Eran tiempos de poca disciplina, pero de enorme entusiasmo y creatividad. Eran tiempos en que los programadores a menudo entraban en otros sistemas, algunas veces con buena intención y otras con mala inten- ción. La actitud que prevalecía parecía ser la de «Hazlo rápidamente, y entra en el campo, que nosotros lo limpiaremos (y mejor sería que entendieras lo que realmente queremos construir) cuando actuemos». ¿Le suena familiar?

En una mesa redonda virtual publicada en IEEE Software [PRE98], mantuve en firme mi postura en relación con la ingeniería de Web:

Me parece que cualquier producto o sistema importante es merecedor de recibir una ingeniería. Antes de comenzar a construirlas, lo mejor es entender el problema, diseñar una solución viable, implementarla de una manera sólida y comprobarla en profundidad. Probablemente también se deberían controlar los cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos para asegurar la calidad del resultado final. Muchos de los que desarrollan Webs no dicen lo mismo; ellos piensan que su mundo es realmente diferente, y que simplemente no se van a aplicar los enfoques de ingeniería del software convencionales.

&Qué es? Los sistemas y aplicaciones (WebApps) basados en Web hacen posible que una población extensa de usuarios finales dispongan de una gran variedad de contenido y funcionalidad La ingeniería Web no es un clónico per- fecto de la ingeniería del software, pero toma prestado muchos de los conceptos y principios básicos de la ingenie- ría del software, dando importancia a las mismas actividades técnicas y de gestión. Existen diferencias sutiles en la forma en que se llevan a cabo estas actividades, pero la filosofía primordial es idéntica dado que dicta un enfoque disciplinado para el desarrollo de un sistema basado en computadora.

&Quién lo hace? Los ingenieros Web y los desarrolladores de contenido no técnicos crean las WebApps.

&Por qué es importante? A medida que las WebApps se integran cada vez más en grandes y pequeñas compa-

ñías (por ejemplo, comercio electróni- co), y cada vez es más importante la necesidad de construir sistemas fiables, utilizables y adaptables. Esta es la razón por la que es necesario un enfoque disciplinado para el desarrollo de WebApps.

&Cuáles son los pasos a seguir ? Al igual que cualquier disciplina de inge- niería, la ingeniería Web aplica. un enfoque genérico que se suaviza con estrategias, tácticas y métodos especializados. El proceso de ingeniería Web comienza con una formulación del problema que pasa a resolverse con las WebApps. Se planifica el proyecto y se analizan los requisitos de la WebApp, entonces se lleva a cabo el diseño de interfaces arquitectónico y del navegador. El sistema se implementa utilizando lenguajes y herramientas especializados asociados con la Web, y entonces comienzan las prue-

s. Dado que las WebApps están e n nte evolución, deben de esta- e los mecanismos para el con-

trol de configuraciones, garantía de calidad y soporte continuado.

4 Cuál es el producto obtddo? La elaboración de una gran variedad de productos de trabajo de ingenierfa Web (por ejemplo, modelos de análisis. modelos de diseño, procedimientos de pruebas). Y como producto final l a WebApp operativa.

1 Cómo puedo estar seguro de que lo he hecho correctamente? Apli- cando las mismas prácticas SQA que se aplican en todos los procesos de inge- niería del software -las revisiones téc- nicas formales valoran los modelos de análisis y diseiío-; las revisiones espe- cializadas tienen en consideración la usabilidad y la comprobación se aplica para descubrir errores en el contenido, funcionalidad y compatibilidad.

52 1

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRdCTICO

Esto nos lleva a formular una pregunta clave: ¿Pue- den aplicarse principios, conceptos y métodos de inge- niería en el desarrollo de la Web? Creo que muchos de ellos sí se pueden aplicar, pero su aplicación quizás requiera un giro algo diferente.

Pero, ¿qué ocurriría si estuviera equivocado?, y ¿si persiste el enfoque actual y específico para ese desarrollo de la Web? Con la ausencia de un proceso disciplinado para sistemas basados en Web, cada vez nos

preocupa más la manera en que nos podemos enfrentar con problemas serios para obtener éxito en el desarrollo, empleo y «mantenimiento» de estos sistemas. En esencia, a medida que entramos en el nuevo siglo, la infraestructura de las aplicaciones que se están creando hoy en día puede llevamos a algo que se podría llamar «Web enmarañada». Esta frase connota un cúmulo de aplicaciones basadas en Web pobremente desarrolladas y con una probabilidad de fallo bastante alta. Y lo que es peor, a medida que los sistemas basados en Web se van compli- cando, un fallo en uno de ellos puede propagar y propagará problemas muy extensos en todos. Cuando ocurra esto, la confianza en Internet se puede romper provocando resultados irremediables. Y lo que es aún peor, puede conducir a una regulación gubernamental innecesaria y mal concebida, provocando daños irreparables en estas tec- nologías singulares.

Con objeto de evitar una Web enmarañada y lograr un mayor éxito en el desarrollo y aplicación de sistemas basados en Web complejos y a gran escala, existe una necesidad apremiante de enfoques de ingeniería Web disci- plinada y de métodos y herramientas nuevos para el desarrollo, empleo y evaluación de sistemas y aplicaciones basados en Web. Tales enfoques y técnicas deberán tener en cuenta las características especiales en el medio nuevo, en los entornas y escenarios operativos, y en la multiplicidad de perfiles de usuario implicando todo ello un reto adicional para el desarrollo de aplicaciones basadas en Web.

La Ingeniería Web (IWeb) está relacionada con el establecimiento y utilización de principios científicos, de ingeniería y de gestión, y con enfoques sistemáticos y disciplinados del éxito del desarrollo, empleo y mantenimiento de sistemas y aplicaciones basados en Web de alta calidad [MUR99].

'. ,.., . - , B , .

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 que se tratan en el Capítulo 1. 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 comu- nicaciones internas y relaciones externas, y de arte y tecnología» [POW98]. 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 diver- sa 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 comuni- cación a través de redes de una organización) o una Extranet (comunicación entre redes).

las WebApps son intensivas de red, controladas por el contenido y en continua evolución. Estos atributos tienen un profundo impacto dentro de la forma en que se lleva a coba lo IWeb.

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.

I En esta categoria se incluyen unos sitios Web completos, funcio nalidad especializada dentro de los sitios Web y aplicaciones de proceso de informacion que residen en Internet, en una Intranet o en una Extranet

En el contexto de este capitulo el termino «aplicacion Webn abar- cara todo, desde una pagina Web simple que podria ayudar a un con- sumidor a calcular el pago de un alquiler de un coche hasta un sitio Web completo que proporcione los servicios completos para viales de negocios y de vacaciones

522

Evolución continua. 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 [LOW99] trata este tema con el siguiente escrito:

La ingeniena 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 des- tinado 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.. .podn- amos 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 permite 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 semanas3. Los desarrolladores deberán utilizar los métodos de planificación, análisis, diseño, imple- mentación y comprobación que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.

No hay duda de que la inmediotez o menudo prevalece en el desorrolla de las WebApps, pero hay que tener cuidodo, porque el hecho de hocer olga rápidomente no significo tener el privilegio de hacer un irobajo de ingenierío pobre. lo rápido y erróneo roros veces tiene un resultado acepiable.

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

Páginas Web sofisticadas pueden elaborarse en pocas horas

CAPfTULO 29 INGENIERfA WEB

medidas de seguridad en toda la infraestructura que apo- ya 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 [DAR99]:

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;

¿Cómo se pueden tategorizar las WebApps?

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 domi- nio de la aplicación del portal; acceso a bases de datos: el usuario consulta en una base de datos grande y extrae información; aZmacenes de datos: el usuario hace una consulta en una colección de bases de datos grande y extrae infor- mación. Las características y las categorías destacadas ante-

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

29.1.1. Atributos de calidad Todas las personas que hayan navegado alguna vez por la Web o hayan utilizado una intranet de una compañía pue-

523

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

den opinar sobre lo que hace una «buena» WebApp. Los puntos de vista individuales vm’an enormemente. Algu- nos usuarios disfrutan con gráficos llamativos, en cambio otros solo quieren un texto sencillo. Algunos exigen infor- mació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?

Arbol detallado de los requisitos de calidad para WebApps

En realidad, todas las características generales de la calidad del software estudiadas en los Capítulos 8, 19 y 24 se aplican también a las WebApps. Sin embargo, las características más relevantes -usabilidad, fiabilidad, eficiencia y capacidad de mantenimiento- pro- porcionan una base Útil para evaluar la calidad de los sistemas basados en Web.

Olsina y sus colaboradores [OSL99] 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.

Facilidad de corrección

FIGURA 29.1. Árbol de requisitos de calidad (OSL 99).

29.1.2. 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 en los Capí- tulos 27 y 28 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 preconstmidos, 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. Para más información, el lector interesado puede consultar en esta bibliografía: [ATK97], [KAE991 y [BRE991.

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. Para más información sobre XML, el lector interesado deberá consultar [PAR991 y [STL99].

Estándares de Internet

524

CZC

..... .. ,.:. .. ., , .~ . 1. “ . ..

83M VJü3IN33NI 62 O?il.LldV3


cliente. Es en este punto en donde se solicitan cambios (tienen lugar ampliaciones del ámbito). Estos cambios

se integran en la siguiente ruta mediante el flujo incremental del proceso.

La formulación y el análisis de sistemas y aplicaciones basados en Web representan una sucesión de actividades de ingeniería Web que comienza con la identifica- ció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.

29.4.1. Formulación Powell [POW98] sugiere una serie de preguntas que deberán formularse y responderse al comienzo de la eta- pa 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?

¿Qué preguntas se deberían hacer

para formular el problema?

La respuesta a estas preguntas deberá ser de lo más sucinto posible. Por ejemplo, supongamos que el fabri- cante 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 confi- gurar y comprar todos los componentes necesarios para insta- lar un sistema de seguridad en casa o en su comercio.

Es importante destacar que en esta frase no se ha pro- porcionado 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 interme- diarios, y mejorando de esta manera los márgenes de benefi- cios. 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 dma- cenes de ventas.

Finalmente, la compañía define la demografía para la WebApp: «Los usuarios potenciales de HogarSegu- roInc.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 [GNA99]:

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.

"*% c V E Poro toda WebApp deberán definirse metas informativos y aplicables.

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 ins- talación (es decir, sobre la casa, oficina/almacén rninoris- ta) 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 antece- dentes, conocimiento, preferencias e incluso más» [GNA99]. En el caso de HogarSeguroInc.com, el perfil de usuario identificará las características de un com- prador 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

poderse aplicar la afirmación de meta siguiente:

HogurSeguro ya se ha utilizado anteriormente como ejemplo en el libro.

526


la afirmación del ámbito para la WebApp (Capítulo 5). En muchos casos, las metas ya desarrolladas se integran en la afirmación del ámbito. Además es Útil, no obstan- te, 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 apli- cació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.

29.4.2. Análisis Los conceptos y principios que se trataron para el aná- lisis de los requisitos del software (Capítulo 11) 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 (Capítulo 12).

Análisis de la interacción. Se trata de la descrip- ción detallada de la interacción del usuario y la WebApp. Para proporcionar descripciones detalladas de esta interacción se pueden desarrollar casos prácti- cos (Capítulo 11).

Análisis funcional. Los escenarios de utilización (casos de uso) creados como parte del análisis de inte- racció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 des- cripció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

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

Referencia 3 Web Uno fuente volioso de líneas generales prácticos poro el diseño de sitios Web se puede enconbar en www.ibm.tom/ibm/eas y/design/lower/ 1060100.html

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

Principios y métodos de diseño. Es importante destacar que los conceptos y principios del diseño estudiados en el Capítulo 13 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 con- ducirá a sistemas y aplicaciones basados en Web más fáciles de adaptar, mejorar, probar y utilizar.

Cuando se crean aplicaciones Web se pueden reutili- zar 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 interac- túan mediante un protocolo de comunicación algo similar a la mensajería. De hecho, la notación de diagramas

527


propuesta por UML (Capítulos 21 y 22) 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 inte- ractivas (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 aplica- ció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 [NAN98] describen este elemento de diseño reutilizable de la siguiente manera:

Lineal con flujo o pciona I Lineal

FIGURA 29.3. Estructuras lineales.

Lineal con desviaciones

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 sola- mente 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

29.5.1. 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 deta- llados del contenido de la información que se presenta- rá como parte de la WebApp.

la mopria de las estructuras de las WebApps simplemente aparecen. Evite esto trampa. Estoblezco el diseña estructural de la WebApp explicitamente antes de empezar a desarrollar los detalles de la pógina y de la navegación.

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 filoso- fía de navegación (Sección 29.5.3) establecidos. Cuan- do el encargado de la arquitectura va a realizar el diseño de una WebApp típica puede elegir entre cuatro fuentes diferentes [POW98].

¿Cuáles son las opciones disponibles para el diseño de

una WebApp?

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 suce- sió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 informa- ción específica en un orden específico. En tales casos,

El diseño del contenido es una actividad no técnica que llevan a cabo redactores publicitarios, artistas, diseñadores gráficos y otros que generan el contenido de las WebApps. Para más información, véase IDlN98) y \LYN99].

CAPÍTULO 29 INGENIERfA WEB

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

FIGURA 29.4. Estructura reticular.

Las estructuras reticdares (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 ven- de palos de golf. La dimensión horizontal de la retícula representa el tipo de palo en venta (por ejemplo, made- ras, 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 [POW98].

"*% C V E Las estructuras reticulares funcionan bien cuando el contenido puede organizarse categóricamente en dos dimensiones o más.

Las estructurasjerúrquicas (Fig. 29.5) son sin duda la arquitectura WebApp más común. A diferencia de la divi- sión de jerarquías de software estudiadas en el Capítulo 14, 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 nave- gación rápida por el contenido de la WebApp, puede ori- ginar también confusión por parte del usuario.

El ocoplomiento es un temo engoñoso poro lo orquiteciuro de los WebApps. Por un lodo, focilita lo novegoción. Pero, por otro, también puede hocer que el usuorio use pierdo». No rehogo conexiones horizontales dentro de uno jerorquío.

FIGURA 29.5. Estructuras jerárquicas.

Una estructura en red o de «web pura» (Fig. 29.6) se asemeja en muchos aspectos a la arquitectura en evo- lució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.

FIGURA 29.6. Estructura en red o (cweb pura)).

Las estructuras arquitectónicas estudiadas en los párrafos anteriores se pueden combinar para formar estruc-

529


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

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

Patrones de diseño

En los Copitulos 14 y 22 se puede sncontror mbs informa¿& sobre las configuraciones de diseh.

Cuando dentro de una WebApp se requiere la funcionalidad del proceso de datos, pueden aplicarse los patrones de diseño arquitectónicas 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 [BER98]:

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

regla

Anillo de Web: una configuración que implementa un «gran ciclo que enlaza hipertextos enteros via- jando por un tema» [BER98]. Contorno: un patrón que aparece cuando varios ciclos inciden en otro, permitiendo navegar por rutas defi- nidas 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éc- nica» 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 la páginas Web para permitir que un usuario tenga una guía de nave- gación consecuente independientemente de la loca- lización de la WebApp. Las configuraciones de diseño de hipertexto aue se

han descrito anteriormente se pueden rekilizar a medida que el contenido va adquiriendo el formato que per- mitirá la navegación a través de una WebApp.

29.5.2. 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 lle- varlo 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án- tica de la navegación de cada uno de estos roles sería diferente.

El diseñador de WebApps crea una unidad semánti- ca de navegación (USN) para cada una de las metas asociadas a cada uno de los roles de usuario [GNA99]. 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 [GNA99] describen la USN de la siguiente manera:

La estructura de una USN se compone de un conjunto de subestructuras de navegación que llamarnosformas de nave- gació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 tan- to, 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.

530


@& CLAVE

Una USN se compone de un coniunto de subestructuras de navegación llamadas ((formas de navegación)) (WoN). Una USN representa una meta de navegación específica para un tipo específico de usuario.

Durante las etapas iniciales del diseño de navega- ció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 nave- gació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ísti- ca 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 debe- rá 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

29.5.3. 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 consideracio- nes adicionales.

con los sitios

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

do, 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» inmediata- mente al usuario potencial. Nielsen y Wagner [NIE96] 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.

¿Cuáles son algunas de las líneas generales

básicas para el diseño de la interfaz de un sitio Web?

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

Referencia 3 We6 Uno de los mejores grupos de recursos de usabilidad de la Web ha sido recogido por el Grupo de Usabiiidad, y se puede encontrar en la dirección www.usability.com/umi-links.htm

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.

53 1


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 necesaria- mente 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. Los lectores interesados pueden consultar [SAN96], [FLE98], [ROS98], o [LYN99] entre los cientos de ofertas que existen como guía.

En el Capítulo 17, se destacó que las pruebas son el proceso de ejercitar el software con la intención de encontrar (y por último corregir) los errores. Esta filosofía fundamental no se cambiará para el caso de las WebApps. De hecho, dado que los sistemas y aplicaciones basados en Web residen en una red e interoperan con muchos sistemas operativos diferentes, navegadores, plataformas de hardware, y protocolos de comunicación, la búsqueda de errores representa un reto significativo para los ingenieros Web.

¿Qué pasos hay que seguir para la comprobación de una

WebApp?

El enfoque de las pruebas de las WebApps adopta los principios básicos de todas las pruebas del software (Capí- tulo 17) y aplica estrategias y tácticas que ya han sido recomendadas para los sistemas orientados a objetos (Capí- tulo 23). 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 orto- grá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.

para los que se sabe qué particular, PPS), Y se

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 permite 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 nave- gación (por ejemplo, un caso en donde el usuario no pueda leer un nodo de navegación). Además, los enla-

ces de navegación (Sección 29.5.2) son revisados para asegurar su correspondencia con los especifi- cados 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 caractens- ticas 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.

tos esírategios de integmcii se abarcan en los Capítulos 18 y 23.

4. Se construye la arquitectura, se realizan las pruebas de integración. La estrategia para la prueba de inte- gració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 mez- clada 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 (Capí- tulo 23) 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 com- probació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

532


6.

sistemas y aplicaciones basados en Web se centra en acciones visibles del usuario y en salidas reconoci- bles 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. 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 navegadores7 y protocolos de comu- nicación. Entonces se llevan a cabo pruebas para des-

cubrir 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 inte- racció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 evo-

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

29.7 P R C ) B L E M A S T I h N Dada la inmediatez de las WebApps, sería razonable preguntarse: ¿necesito realmente invertir tiempo esfor- zá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 com- plicada. 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 detprofesionales. 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.

los actividodes asociados con lo gestión de proyectos de soíiware se esíudion en lo Porte Segunda de este libro.

29.7.1. El equipo de IWEB La creación de una buena aplicación Web exige un amplio abanico de conocimientos. Tilley y Huang [TIL99] 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 dis-

7 Los navegadores son excelentes para implementar sus propias inter- pretaciones ((estándar. ligeramente diferentes de HTML y Javascript. Para un estudio de temas de compatibilidad, véase www.browser- caps.com.

ciplinas.. .» 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 conjun- to 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 del Capítulo 3. 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án- dares de Intemet, 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:

¿Qué papeles juegan las personas que forman

parte del equipo de 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 conteni-

Estos roles se han adaptado de Harsen y sus colaboradores [HAN99].

533

INGENiERfA DEL S O F T W A R E . U N E N F O Q U E PRÁCTICO

do. 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 pro- ductores 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 debe- rá 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 tan- to 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, imple- mentació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 Weh 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 implemen- tación; la medición y análisis del tráfico del sitio Web; la coordinación de los procedimientos de control de cambios (Sección 29.7.3); 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.

29.7.2. Gestión del proyecto En la Parte Segunda de este libro se tuvieron en consi- deración todas y cada una de las actividades global- mente 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 planifi- cación temporal y el rastreo, SQA y CGS, se estudia- ron en detalle. En teoría, la mayoría de las actividades de gestión de proyectos, si no todas, estudiadas en capí- tulos anteriores, 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 sus- tancial" de WebApps a proveedores que (supuesta- mente) son especialistas en el desarrollo de sistemas y aplicaciones basados en Web. En tales casos, un nego- cio (el cliente) solicita un precio fijo para el desarrollo de una WebApp a uno o más proveedees, evalúa los precios de los candidatos y selecciona un proveedor para hacer el trabajo. Pero, ¿qué es lo que busca la organi- zación contratista?, ¿cómo se determina la competen- cia de un proveedor de WebApps?, ¿cómo se puede saber si un precio es razonable?, ¿qué grado de planifi- cación, programación temporal, y valoración de riesgos se puede esperar a medida que una organización (y su subconstratista) 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étri- ca de IWeb. De hecho, tampoco han surgido muchos estudios sobre lo que esas métricas podrían ser. Por tan- to, la estimación es puramente cualitativa -basada en

9 Se recomienda que lectores no familiarizados con los conceptos básicos de gestión de proyectos revisen en este momento el Capí- tul0 3 .

l o Aun cuando los datos de industria fiables son dificiles de encontrar, es seguro decir que este porcentaje es considerablemente mayor que el que se encuentra en el trabajo del software convencional.

534

CAPfTUI.0 29 INGENIERfA WEB

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 pro- gramas temporales definidos?

En tercer lugar, el análisis de riesgos y la programa- ción temporal se predican bajo un entendimiento claro del ámbito del proyecto. Y sin embargo, la característi- ca de «evolución continua» tratada en la Sección 29.1 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 contro- larse 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 con- sideración una serie de líneas generales.

Inicio de un proyecto. Aun cuando la subcontrata- ció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 subcontrata- ción para hacer el trabajo.

1. Muchas de las actividades de análisis tratadas en la Sección 29.3 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

2.

3.

4 .

una WebApp con éxito. Esta información deberá de documentarse en una especificación del producto. Se deberá desarrollar internamente un diseño apro- ximado 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 preli- minares del proyecto). El diseño deberá incluir la indi- cación del proceso interactivo que se va a llevar a cabo (por ejemplo, formularios, entrada de pedidos). Se deberá desarrollar una planijicación temporal apro- ximada del proyecto, incluyendo no solo las fechas finales de entrega, sino también las fechas hito (signi- ficativas). Los hitos deberán adjuntarse a las versiones de entrega posibles a medida que avanza el proyecto. Se deberá identificar el grado de supervisión e inte- racció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 ante-

riores deberá de organizarse en una solicitud de opciones que se transmite a los proveedores candidatos".

Selección entre los proveedores de subcontrata- ción candidatos. En los últimos años han surgido miles de compañías de «diseño Web» para ayudar a las empre- sas 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 candida- to, 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 cuida- dosamente las muestras de trabajo del proveedor simi-

I I Si el trabajo de desarrollo de la WebApp es dirigida por un grupo interno, nada cambia. El proyecto se inicia de la misma manera.

535

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

lares 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. Evidentemen- te 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 inver- sión y justificar así el proyecto? ¿Es el proveedor de la oferta una muestra clara de la profesionalidad y experiencia requeridos?

Si la respuesta es «sí», el precio ofertado es justo. El grado de gestión del proyecto que se puede espe-

rar 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 pla- nificació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 escribir- se. 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 plani- ficació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 reco- nozcan 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 (Capítulo 2). 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 revi- sió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 conien- te continua de cambios, pero reconociendo la característica de evolución continua de la mayoría de las WebApps.

Las líneas generales sugeridas anteriormente no pre- tenden 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.

29.7.3. 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 sofisti- cados para el comercio electrónico. A medida que las WebApps van creciendo en importancia para la super- vivencia 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 auto- rizada 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ómica- mente desagradables e incluso desastrosas.

Se pueden aplicar las estrategias generales para la gestión de la configuración del software (GCS) descri- tas en el Capítulo 9, 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 tener- se en consideración cuatro temas [DAR99]: 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ági- nas, 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 (Capítulo 9). 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éc- nicas convencionales de modelado de datos (Capítulo 1 1), adjuntando un conjunto de propiedades especializa- das a cada objeto. La naturaleza estática y dinámica de

536


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 aplicanya un componente de formularios (objeto permanente).

Es esencial conirolor el cambio durante los proyectos Web, aun cuando puede hocene de formo exagerado. Empiece por los procedimientos de control de cambio de relativo informalidad Kopihlo 91. lo meto inicial será evitar los efectos de trinquete en cambios incontrolodos.

Personas. Dado que un porcentaje significativo del desarrollo de las WebApps continúa realizándose depen- diendo 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 ante- cedentes en ingeniería del software y no tienen ningún conocimiento de la necesidad de una gestión de confi- guración. La aplicación crece y cambia de forma incon- trolada.

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 sig- nificativamente cuando se implementan las intercone- xiones que existen dentro de los sistemas de información, bases de datos, almacenes de datos y pasa- relas 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án ser directamente proporcionales 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 [DAR991 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á toda- vía en su infancia. Un proceso convencional de GCS puede resultar demasiado pesado y torpe. La gran mayo- ría de las herramientas GCS no tienen las característi- cas que permiten adaptarse fácilmente a la IWeb. Entre los temas que quedan por tratar se encuentran los siguientes [DAR99]:

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 cuasipubli- cació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 con- figuració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-ma gestión de configuración eficaz para la k e b .

Se puede argumentar que el impacto de los sistemas y aplicaciones basados en Web es el acontecimiento más significativo en la historia de la informática. A medida que las WebApps crecen en importancia, el enfoque de ingeniería de Web disciplinado ha empezado a evolucionar -basado en principios, conceptos, procesos y métodos que se han desarrollado para la ingeniería del software-.

Las WebApps son diferentes de otras categorías de software informático. Son intensivas de red, están gober-

nadas por el contenido y están en continua evolución. La inmediatez que conduce a su desarrollo, la necesidad primordial de seguridad al funcionar, y la demanda de esté- tica y la entrega del contenido funcional son otros factores diferenciadores. Durante el desarrollo de la WebApp hay tres tecnologías que se integran con otras de ingeniería del software convencional; desarrollo basado en componentes, seguridad y lenguajes de notas estándar.

El proceso de ingeniería de Web comienza con la for- mulación -una actividad que identifica las metas y los

537

INGENlERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

objetivos de la WebApp-. La planificación estima el coste global del proyecto, evalúa los riesgos asociados con el esfuerzo del desarrollo y define una programación temporal del desarrollo. El análisis establece requisitos técnicos e identifica los objetos del contenido que se incor- porarán en la WebApp. La actividad de ingeniería incor- pora dos tareas paralelas: diseño del contenido y diseño técnico. La generación de páginas es una actividad de construcción que hace un uso extenso de herramientas automatizadas para la creación de WebApps, y la com-

probación ejercita la navegación de la WebApp, inten- tando descubrir errores en la función y el contenido, y asegurando mientras tanto que la WebApp funcione correctamente en diferentes entomos. La ingeniería de Web hace uso de un modelo de proceso iterativo e incremental porque la línea temporal del desarrollo para la WebApp es muy corta. Las actividades protectoras apli- cadas durante el trabajo de la ingeniería del software -SQA, GCS, gestión de proyectos- se aplican a todos los proyectos de ingeniería de Web.

[ATK97] Atkins, D., et al., Internet Security: Professional Reference, New Riders Publishing, 2.& ed., 1997.

[BER98] Bemstein, M., «Pattems in Hypertext», Proc. gth ACM Conf. Hypertext, ACM Press, 1998, pp. 21-29.

[BRA97] Bradley, N., The Concise SGML Companion, Addi- son-Wesley, 1997.

[BRE99] Brenton, C., Mastering Network Security, Sybex, Inc., 1999.

[BUS961 Buschmann, E et al., Pattern-Oriented Software Architecture, Wiley, 1996.

[DAR991 Dart, S., «Containing the Web Crisis Configura- tion Managemenb, Proc. Is' ICSE Workshop on Web engineering, ACM, Los Ángeles, Mayo de 1999".

[DIN98] Dinucci, D., M. Giudice y L. Stiles, Elements of Web Design: The DesignerS Guide to a New Medium, 2.3 ed., Peachpit Press, 1998.

[GAM95] Gamma, E. et al., DesignPatterns, Addison-Wes- ley, 1998.

[GNA99] Gnaho, C., y E Larcher, «A User Centered Me- thodology for Complex and Customimizable Web Appli- cations engineerinp, Proc. 1st ICSE Workshop on Web engineering, ACM, Los Ángeles, Mayo de 1999.

[HAN991 Hansen, S., Y. Deshpande y S. Murgusan, «A Skills Hierarchy for Web Information system Development», Proc. 1"' ICSE Workshop on Web Engineering, ACM, Los Ángeles, Mayo de 1999.

[ISA95] Isakowitz, T. et al., «RMM: A Methodology for Structured Hypermedia Design», CACM, vol. 38, n." 8, Agosto de 1995, pp. 43-44.

[KAE99] Kaeo, M., Designing Network Security, Cisco Press, 1999.

[LOW99] Lowe, D., «Web Engineering or Web Gardening?», WebNet Journal, vol. 1, n." 2, Enero-Marzo de 1999.

[LYN99] Lynch, P.J., y S. Horton, Web Style Guide: Basic Design Principles for Creating Web Sites, Yale University Press. 1999.

[MUR991 Murugesan, S., WebE Home Page, http://fist- serv.macarthur.uws.edu.au./san/WebHome, Julio de 1999.

[NAN98] Nanard, M., y P. Kahn, «Pushing Reuse in Hyper- media Design: Golden Rules, Design pattems and cons- tructive Templates», Proc. gth ACM conf. On Hypertext and Hypermedia, ACM Press, 1998, pp. 11-20.

[NIE96] Nielsen, J., y A. Wagner, «User Interface Design for the WWWD, Proc. CHI' 96 conference on Human Factors in Computing systems, ACM, Press, 1996, pp. 330-331.

[NOR99] Norton, K., «Applying Cross Functional Metho- dologies to Web Development», Proc. I s t ICSE Works- hop on Web Engineering, ACM, Los Ángeles, Mayo de 1995.

[OSL99] Olsina, L. et al., «Specifying Quality Characteris- tics and Attributes for Web Sitesm, Proc. Is' Workshop on Web Engineering, ACM, Los Angeles, Mayo de 1995.

[PAR991 Pardi, W.J., XML in Action, Microsoft Press, 1999.

[POW98] Powell, T.A., Web Site engineering, Prentice-Hall, 1998.

[PRE98] Pressman, R.S. (moderador), «Can Intemet-Based Applications be Engineered?», IEEE Sofmare, Septiem- bre de 1998, pp. 104-110.

[ROS981 Rosenfeld, L., y P. Morville, Information Architec- ture for the World Wide Web, O'Reilly & Associates, 1998.

[SAN961 Sano, D., Designing Large-Scale Web Sites: A Visual Design Methodology, Wiley 1996.

[SCH96] Schwabe, D., G. Rossi y S. Barbosa, «Systematic Hypermedia Application Design with OOHDMD, Proc. Hypertext ' 96, pp. 116-128.

[SPO98] Spool, J.M., et al., Web Site Usability: A Desig- ner's Guide, Morgan Kaufmann Publishers, 1998.

[STL99] St. Laurent, S., y E. Cerami, Building XML Appli- cations, McGraw-Hill, 1999.

[TIL99] Tilley, S., y S. Huang, «On the emergence of the Renaissance Software engineer», Proc. 1"' ICSE Workshop on the Web Engineering, ACM, Los Angeles, Mayo de 1999.

I2 Los procedimientos del Primer Taller ICSE sobre Ingeniena del %IR- ware se publican en la red en http://ñstserv.marcarthur. uws.edu.au/san/icse99-WebE/ICSE99-Web-E-~/default.htm

538


29.1. ¿Existen otros atributos genéricos que diferencien a las WebApps de otras aplicaciones de software? Enumere 2 Ó 3. 29.2. ¿Cómo se juzga la calidad de un sitio Web? Confeccio- ne una lista de 10 atributos de calidad prioritarios que consi- dere más importantes. 29.3. Realice una pequeña investigación y realice un trabajo de 2 ó 3 páginas que resuma una de las tres tecnologías que se destacaron en la Sección 29.1.2. 29.4. Utilizando un sitio Web real como ejemplo, ilustre las diferentes manifestaciones del «contenido» de la WebApp. 29.5. Responda a las tres preguntas de formulación para un sitio Web con el que esté familiarizado. Desarrolle una afir- mación de ámbito para el sitio Web. 29.6. Desarrolle un conjunto de perfiles para HogarSegu- roInc.com o un sitio Web asignado por su profesor. 29.7. Desarrolle una lista completa de metas informativas y aplicables para HogarSeguroInc.com o un sitio Web asignado por su profesor. 29.8. Elabore un conjunto de casos de uso para HogarSegu- roInc.com o un sitio Web asignado por su profesor. 29.9. ¿En qué difiere el análisis del contenido del análisis funcional y de interacción?

29.10. Realice un análisis del contenido para HogarSegu- roInc.com o para un sitio Web asignado por su profesor. 29.11. Sugiera tres «reglas de oro» que servirán como guía en el diseño de WebApps. 29.12. ¿En qué difiere una configuración de diseño WebApp de una plantilla? 29.13. Seleccione un sitio Web con el que esté familiarizado y desarrolle un diseño arquitectónico razonablemente completo para el sitio. ¿Qué estructura arquitectónica seleccionó el diseñador del sitio? 29.14. Haga una investigación breve y escriba 2 ó 3 páginas que resuman el trabajo actual en las configuraciones de dise- ño de las WebApps. 29.15. Desarrolle un diseño arquitectónico para HogarSegu- roInc.com o para un sitio Web asignado por su instructor. 29.16. Utilizando un sitio Web real como ejemplo, desarrolle una crítica de su interfaz de usuario y haga una recomenda- ción que lo mejore. 29.17. Describa la manera en que una gestión de proyecto para sistemas y aplicaciones basados en Web difieren de la gestión de proyecto para el software convencional. ¿En qué se asemeja?

Durante los últimos años se han publicado cientos de libros que tratan uno o más temas de ingeniería de Web, aunque relativamente pocos tratan todos los aspectos. Lowe y Hall (Hypertext and the Web: An Engineering Approach, Wiley, 1999), y Powell [POW98] abarcan razonablemente estos temas. Norris, West y Warson (Media Engineering: A Quide to Developing Information Products, Wiley, 1997), Navarro y Khan (Effective Web Design: Master the Essentials, Sybex, 1998), Fleming y Koman (Web Navigation: Designing the User Experience, O'Reilly & Associates, 1998), y Sano [ SAN961 también abarcan aspectos importantes del proceso de ingeniería.

Además de [LYN99], [DIN98] y [SPO98], los siguientes libros proporcionan una guía útil para los aspectos del dise- ño de WebApps tanto técnicos como no:

Baumgardt, M., Creative Web Design: Tips and Tricks Step by Step, Springer Verlag, 1998.

Donnelly, D. et al., Cutting Edge Design: The Next Gene- ration, Rockport Publishing, 1998.

Holzschlag, M.E., Web by Design: The Complete Guide, Sybex, 1998.

Niederst, J., y R. Koman, Web Design in a Nutshell: A Desktop Quick Reference, O'Reilly & Associates, 1998.

Weinman, L., y R. Prirouz, Click Here: Web Communi- cation Design, New Riders Publishing, 1997.

Menasce y Almeida (Capacis Planning for Web Perfor- mance: Metrics, Models, and Methods, Prentice-Hall, 1998) tratan la valoración cuantitativa del rendimiento de las WepApps. Amoroso (Intrusion Detection: An Introduction to Internet Surveillance, Correlation, Trace Back, Traps, and Response, 1ntrusion.Net Books, 1999) proporciona una guía detallada para los ingenieros de Web que están especializados en temas de seguridad. Umar (Application (Re)Enginee- ring: Building Web-Based Applications and Dealing With Legacies, Rentice-Hall, 1997) estudia estrategias para la trans- formación (reingeniería) de sistemas anteriores en aplicaciones basadas en Web. Mosley (Client Sewer So f iare Testing on the Desk Top and the Web, Prentice-Hall, 1999) ha escri- to uno de los mejores libros que estudian los temas de com- probación asociados con WebApps.

Haggard (Survival Guide to Web Site Developrnent, Microsoft Press, 1998) y Siegel (Secrets of Successful Web Sites: Project Management on the World Wide Web, Hay- den Books, 1997) proporcionan una guía para el gestor que debe de controlar y hacer un seguimiento del desarrollo de WebApps.

Una amplia variedad de fuentes de información sobre inge- niería de Web está disponible en Internet. Una lista amplia y actualizada de referencias en sitios (páginas) web se puede obtener en http:/www.pressman5.com.

539

INGENIERÍA WEB - Informática Coacalco · cando las mismas prácticas SQA ... plinada y de...

Documents

Transcript of INGENIERÍA WEB - Informática Coacalco · cando las mismas prácticas SQA ... plinada y de...