29-Capítulo Ing. Web

CAPÍTULO
29
INGENIERÍA WEB
L
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
música, vemos películas, obtenemos asesoramiento médico, hacemos reservas de habitaciones en hoteles, vendemos artículos personales, planificamos vuelos en líneas aéreas, conocemos 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 tecnologí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 tecnologí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 intenció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 d e una gran
variedad de contenido y funcionalidad
La ingeniería Web no es un clónico perfectode la ingeniería del software, pero
toma prestado muchos de los conceptos y principios básicos de la ingenierí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 d e contenido no
técnicos crean las WebApps.
&Porqué es importante? A medida
que las WebApps se integran cada vez
más en grandes y pequeñas compa-
ñías (por ejemplo, comercio electrónico), y cada vez es más importante la
necesidad d e 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álesson los pasos a seguir ? Al
igual que cualquier disciplina de ingenierí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 d e l a
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-
52 1
s. Dado que las WebApps están e n
nte evolución, deben de estae los mecanismos para el control de configuraciones, garantía de
calidad y soporte continuado.
4 Cuál es el producto obtddo? La
elaboración de una gran variedad d e
productos de trabajo de ingenierfa Web
(por ejemplo, modelos d e análisis.
modelos de diseño, procedimientos d e
pruebas). Y como producto final l a
WebApp operativa.
1 Cómo puedo estar seguro de que
lo he hecho correctamente?Aplicando las mismas prácticas SQA que se
aplican en todos los procesos de ingeniería del software -las revisiones técnicas formales valoran los modelos de
análisis y diseiío-; las revisiones especializadas tienen en consideración la
usabilidad y la comprobación se aplica para descubrir errores en el contenido, funcionalidad y compatibilidad.
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRdCTICO
Esto nos lleva a formular una pregunta clave: ¿Pueden aplicarse principios, conceptos y métodos de ingenierí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 complicando, 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 tecnologí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 disciplinada 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 comunicaciones 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 diversa de clientes. Una WebApp puede residir en Internet
(haciendo posible así una comunicación abierta par todo
el mundo). De forma alternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación a través de redes de una organización) o una
Extranet (comunicación entre redes).
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 abarcara todo, desde una pagina Web simple que podria ayudar a un consumidor 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
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.
522
CAPfTULO 29
INGENIERfA WEB
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 [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;
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 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.. .podnamos 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.
¿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 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;
aZmacenes 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.
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, implementació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
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-
Páginas Web sofisticadas pueden elaborarse en pocas horas
523
INGENIERfA DEL SOFTWARE. UN ENFOQUE PR A C TI CO
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 infraestructuraque permite
a los que diseñan emplear y personalizar componentesde
terceras partes permitiéndoles así comunicarse unos con
otros y con servicios a nivel de sistemas.
den opinar sobre lo que hace una «buena» WebApp. Los
puntos de vista individuales vm’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?
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- proporcionan 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.
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.
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 -XMLpara 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].
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.
524
8 3 M VJü3IN33NI
CZC
.
. .
.....
.. ,.:
..
. ,
,
.~
.
1.
“
62 O?il.LldV3
INGENIERfA DEL SOFTWARE. UN ENFOQUE PR A CTICO
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 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.
en zonas geográficas en donde actualmente no tenemos dmacenes 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 HogarSeguroInc.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.
29.4.1. Formulación
Powell [POW98] 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?
"*%
c
VE
Poro toda WebApp deberán definirse metas
informativos y aplicables.
¿Qué preguntas
En el contenido de la Web HogarSeguroInc.com,una
meta informativa podría ser la siguiente:
se deberían hacer
para formular el problema?
El sitio proporcionará a los usuarios especificaciones de un
producto detallado, como descripción técnica, instruccionesde
instalación e información de precios.
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:
El examen de las respuestas anteriores llevará a
poderse aplicar la afirmación de meta siguiente:
HogarSeguroInc.com consultará al cliente sobre la instalación (es decir, sobre la casa, oficina/almacén rninorista) que se va a proteger, y dará recomendaciones personalizadas sobre el producto y la configuración que se va
utilizar.
HogarSeguroInc.com5permitirá a los consumidores configurar y comprar todos los componentes necesarios para instalar un sistema de seguridad en casa o en su comercio.
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»
[GNA99]. 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
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 HogarSeguro 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
HogurSeguro ya se ha utilizado anteriormente como ejemplo en el
libro.
526
CAPfTULO 29
INGENIERfA W E B
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 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.
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 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 (Capítulo 11).
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
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 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
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.
3
Referencia 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
527
INGENIERfA DEL SOFTWARE. UN ENFOQUE PR A CTICO
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 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 [NAN98] describen
este elemento de diseño reutilizable de la siguiente
manera:
Lineal
Lineal con flujo
o pciona I
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 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
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 detallados del contenido de la información que se presentará 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 filosofía de navegación (Sección 29.5.3) establecidos. Cuando el encargado de la arquitectura va a realizar el diseño
de una WebApp típica puede elegir entre cuatro fuentes diferentes [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 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,
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 W E B
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.
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).
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.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 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 [POW98].
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 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.
"*%
C
VE
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 divisió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
FIGURA 29.6. Estructura en red o (cweb pura)).
Las estructuras arquitectónicas estudiadas en los
párrafos anteriores se pueden combinar para formar estruc529
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
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.
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 navegación consecuente independientemente de la localizació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 permitirá la navegación a través de una WebApp.
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).
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 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 [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:
En los Copitulos 14 y 22 se puede sncontror mbs
informa¿& sobre las configuracionesde 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 viajando por un tema» [BER98].
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.
La estructura de una USN se compone de un conjunto de
subestructuras de navegación que llamarnosformas 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.
530
CAPfTULO 29
INGENIERfA WEB
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» inmediatamente 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.
@&
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 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
¿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 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.
29.5.3. D i s e ñ 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.
3
Referencia 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
con los sitios
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.
La interfaz de usuario de una WebApp es la «primera
impresión». Independientemente del valor del conteni53 1
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
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. 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 significativopara los ingenieros Web.
ces de navegación (Sección 29.5.2) 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.
¿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 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.
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 integración depende de la arquitectura que se haya elegido
para la WebApp. Si la WebApp se ha diseñado con una
estructurajerá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 (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 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
para los que
se sabe qué
particular,
PPS),Y se
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 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 navegación (por ejemplo, un caso en donde el usuario no
pueda leer un nodo de navegación). Además, los enla532
CAPfTULO 29
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 navegadores7 y protocolos de comunicación. Entonces se llevan a cabo pruebas para des-
29.7
INGENIERfA WEB
cubrir los errores asociados con todas y cada una de
las configuraciones posibles.
7. La WebAppse 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.
PRC)BLEMASTIhN
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 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.
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 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 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ándares 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:
los actividodes asociados con lo gestión de proyectos
de soíiware se esíudion en lo Porte Segunda
de este libro.
¿Qué papeles juegan
las personas que forman
parte del equipo de IWeb?
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-
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-
7 Los navegadores son excelentes para implementar sus propias interpretaciones ((estándar. ligeramente diferentes de HTML y Javascript.
Para un estudio de temas de compatibilidad, véase www.browsercaps.com.
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
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 (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.
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 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 especialistade 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:
29.7.2. 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. 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 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 proveedees, 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
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é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
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
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 planijicación temporal aproximada del proyecto, incluyendo no solo las fechas
finales de entrega, sino también lasfechas 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".
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» 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 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 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
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 simi-
I I Si el trabajo de desarrollo de la WebApp e s 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. 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 requeridos?
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
(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 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 coniente 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 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.
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 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) descritas 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 tenerse 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á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 (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écnicas convencionales de modelado de datos (Capítulo
11), adjuntando un conjunto de propiedades especializadas a cada objeto. La naturaleza estática y dinámica de
536
CAPfTULO 2 9
INGENIERfA WEB
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á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á 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 [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 cuasipublicació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-magestió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 formulación -una actividad que identifica las metas y los
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
aplicanyaun 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.
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 incorporarán en la WebApp. La actividad de ingeniería incorpora 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, intentando 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 aplicadas 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.
[MUR991 Murugesan, S., WebE Home Page, http://fistserv.macarthur.uws.edu.au./san/WebHome,Julio de 1999.
[BER98] Bemstein, M., «Pattems in Hypertext», Proc. gth
ACM Conf. Hypertext, ACM Press, 1998, pp. 21-29.
[NAN98] Nanard, M., y P. Kahn, «Pushing Reuse in Hypermedia Design: Golden Rules, Design pattems and constructive Templates», Proc. gth ACM conf. On Hypertext
and Hypermedia, ACM Press, 1998, pp. 11-20.
[BRA97] Bradley, N., The Concise SGML Companion, Addison-Wesley, 1997.
[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.
[BRE99] Brenton, C., Mastering Network Security, Sybex,
Inc., 1999.
[BUS961 Buschmann, E et al., Pattern-Oriented Software
Architecture, Wiley, 1996.
[NOR99] Norton, K., «Applying Cross Functional Methodologies to Web Development», Proc. Ist ICSE Workshop on Web Engineering, ACM, Los Ángeles, Mayo de
1995.
[DAR991 Dart, S., «Containing the Web Crisis Configuration Managemenb, Proc. Is' ICSE Workshop on Web engineering, ACM, Los Ángeles, Mayo de 1999".
[OSL99] Olsina, L. et al., «Specifying Quality Characteristics and Attributes for Web Sitesm, Proc. Is' Workshop on
Web Engineering, ACM, Los Angeles, Mayo de 1995.
[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.
[PAR991 Pardi, W.J., XML in Action, Microsoft Press, 1999.
[GAM95] Gamma, E. et al., DesignPatterns, Addison-Wesley, 1998.
[POW98] Powell, T.A., Web Site engineering, Prentice-Hall,
1998.
[GNA99] Gnaho, C., y E Larcher, «A User Centered Methodology for Complex and Customimizable Web Applications engineerinp, Proc. 1st ICSE Workshop on Web
engineering, ACM, Los Ángeles, Mayo de 1999.
[PRE98] Pressman, R.S. (moderador), «Can Intemet-Based
Applications be Engineered?», IEEE Sofmare, Septiembre de 1998, pp. 104-110.
[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.
[ROS981 Rosenfeld, L., y P. Morville, Information Architecture for the World Wide Web, O'Reilly & Associates, 1998.
[ISA95] Isakowitz, T. et al., «RMM: A Methodology for
Structured Hypermedia Design», CACM, vol. 38, n." 8,
Agosto de 1995, pp. 43-44.
[SCH96] Schwabe, D., G. Rossi y S. Barbosa, «Systematic
Hypermedia Application Design with OOHDMD,Proc.
Hypertext ' 96, pp. 116-128.
[KAE99] Kaeo, M., Designing Network Security, Cisco
Press, 1999.
[SPO98] Spool, J.M., et al., Web Site Usability: A Designer's Guide, Morgan Kaufmann Publishers, 1998.
[LOW99] Lowe, D., «Web Engineering or Web Gardening?»,
WebNet Journal, vol. 1, n." 2, Enero-Marzo de 1999.
[STL99] St. Laurent, S., y E. Cerami, Building XML Applications, McGraw-Hill, 1999.
[LYN99] Lynch, P.J., y S. Horton, Web Style Guide: Basic
Design Principles for Creating Web Sites, Yale University
Press. 1999.
[TIL99] Tilley, S., y S. Huang, «On the emergence of the
Renaissance Software engineer», Proc. 1"' ICSE Workshop
on the WebEngineering, ACM, Los Angeles, Mayo de 1999.
[SAN961 Sano, D., Designing Large-Scale Web Sites: A
Visual Design Methodology, Wiley 1996.
I2 Los procedimientos del Primer Taller ICSE sobre Ingeniena del %IRware se publican en la red en http://ñstserv.marcarthur.
uws.edu.au/san/icse99-WebE/ICSE99-Web-E-~/default.htm
538
CAPfTULO 29
INGENIERfA WEB
29.10. Realice un análisis del contenido para HogarSeguroInc.com o para un sitio Web asignado por su profesor.
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? Confeccione una lista de 10 atributos de calidad prioritarios que considere 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 afirmación de ámbito para el sitio Web.
29.6. Desarrolle un conjunto de perfiles para HogarSeguroInc.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 HogarSeguroInc.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.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 HogarSeguroInc.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 recomendació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?
Menasce y Almeida (Capacis Planning f o r Web Performance: 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)Engineering: Building Web-Based Applications and Dealing With
Legacies, Rentice-Hall, 1997) estudia estrategias para la transformación (reingeniería) de sistemas anteriores en aplicaciones basadas en Web. Mosley (Client Sewer S o f i a r e Testing
on the Desk Top and the Web, Prentice-Hall, 1999) ha escrito uno de los mejores libros que estudian los temas de comprobació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, Hayden 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 ingenierí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.
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 Generation, 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 Communication Design, New Riders Publishing, 1997.
539