Metodología para evaluar la calidad de aplicaciones web dinámicas mediante

templates

Lic. Esteban Calabria

Universidad Abierta Interamericana
Análisis y Evaluación de Aplicaciones Web
esteban.calabria (at) gmail.com

Abstract El presente trabajo comienza abordando el tema de

El presente trabajo propone una forma de evaluar
aplicaciones web mediante una plantilla que define un
conjunto de características concretas a analizar.
Dicha plantilla debe ser adaptada a cada desarrollo
en particular. Su objetivo es medir cuantitativamente la
calidad para evaluar aplicaciones existents, guiar
desarrollos nuevos, ayudar en las estimaciones y medir
el impacto de temas de calidad en tiempos y costos .
1. Introduction
El desarrollo de una aplicación web de contenido
dinámico propone sus desafios particulares.
Desde el apartado técnico está el amplio abanico de
tecnologías que se deben manejar. Además del esquema
peticion-respuesta del protocolo HTTP[7], .la tecnología
de generación de contenido dinámico elegida (php,
servlets, jsp, asp, asp.net, etc) y el lenguaje html, aparecen
las hojas de estilo (Css) y el javascript.
Si a este escenario agregamos las RIA (rich internet
application) la cosa no termina ahi,. Aparecen tecnicas de
programación como ajax (Asynchronous JavaScript and
XML), un uso aún mas intensivo de Javascript y
tecnologías como flash, flex, silverlight, entre otras.
A lo técnico se le suma el alcance que suele tener este
tipo de aplicaciones donde muchas veces el usuario final
de la misma no está claramente diferenciado.
Es por ello que cada vez se hace mas necesario aplicar
técnicas de ingeniería [6] al desarrollo de este tipo de
aplicaciones para poder lidiar con su complejidad.
Además de que el producto cumpla con los
requerimientos funcionales y este libre de bugs es
necesario aplicar métodos y herramientas que midan la
calidad del producto que se desarrolla [6].
Para ese problema, este trabajo propone una forma de
medir la calidad basándose en una plantilla o template
adaptable a una aplicación web en particular.
calidad de aplicaciones web estableciendo un marco
conceptual. Bajo ese entorno se describe la plantilla de
calidad como propuesta para cuantificar la calidad de un
sitio web.
A la explicación de la planilla se le suma una segunda
sección con una guia de buenas practicas, técnicas y
sugerencias a incluir como parte del template.
Para que la plantilla sea de utilidad debe ser adaptada y
aplicada y de eso trata la última sección del trabajo.
Analiza las distintas formas de adaptar la plantilla a un
sitio web y de que forma influye su evaluacion en el sitio.
Por ultimo se deja abierta la puerta para trabajos futuros
2. Calidad en aplicaciones web
El tema de la calidad [8] es un tema recurrente en el
desarrollo de software. Ya que la misma no es un
concepto absoluto debemos encontrar una forma de
medirla cuantitativamente y enmarcarla en un marco
conceptual. La ISO 9126 propone un modelo para esto
ultimo.
Figura 1. Marco conceptual para el modelo de
calidad
Este trabajo tomará ese modelo como referencia pero
dejará de lado la parte functional y se centrará mas en
aspectos de mantenibilidad, usabilidad y calidad interna.

1.1. Organización del trabajo

3. Plantilla de calidad
Como primera aproximación, este trabajo propone la
generación de un template. En este trabajo nos referiremos
como plantilla, template de plan de calidad o template en
forma indistintas.
Uno de sus objetivos es hacer tangible el concepto de
calidad y cuantificar su evaluación.
Se trata de un documento técnico que abstrae el
conocimiento de un equipo técnico u organización sobre
los puntos que influyen en la calidad de una aplicacion
web. Para ello define una lista de características
cuantificables que se pueden evaluar en una aplicación
web.
Lo más común es que evalue la presencia/ausencia de
dicha característica, aunque alternativamente a veces se
define un valor entre 0 y 100 que dice que porcentaje de
ella se cumple.
Por ejemplo una característica a evaluar puede ser:
todos los links de una página X deben funcionar. Para
ello la plantilla primero debe decir que pasos hay que
seguir para ver que eso ocurrra, por ejemplo, utilizando
algún servicio de verificación de links como link valet[5].
A la hora de evaluar dicha característica, en el caso de
que todos los links funciones se le otorgará un valor de
100, mientras que por otro lado se valuará como 0 si algún
link falla. La forma de determinar la valoración es
arbitraria y debe formar parte de la definición de la
plantilla.
El template es de naturaleza genérica y cubre un
universo de características aplicables a la mayor cantidad
posibles de aplicaciones web. Como se verá más adelante
una instancia posterior contemplará adaptarlo a un sitio en
particular.
3.1. Actualización el template
El template propuesto no es algo fijo sino que es
dinamico y se debe ir actualizando con la esperiencia del
cada proyecto.
A medida que la experiencia del equipo u organización
crezca dicho aumento debe ser plasmado en el template en
forma de características nuevas.
3.2. Características a evaluar
Cada característica a evaluar debe estar definida de la
forma menos ambigua possible. Con ese fin debe estar
acompañada con un instructivo que detalle la forma de
evaluarla. Se recomienda que cada característica tenga un
nombre corto facil de recordar, una descripción detallada
además del tutorial de como evaluarla.
Un aspecto a incluir es en que momento realizar la
evaluación de cada característica. Lo más
recommendable es que sea parte del proceso de
integración continua y se haga en forma automática. Otra
alternativa menos segura es hacer reviews periodos de
código.
Sobre este aspecto Franca Garzotto presenta una
clasificación de las diferentes formas de evaluación
[12]:
1. Automáticos: aplicando software que realizan
evaluación.
2. Métodos empíricos: observando usuarios que usan el
sistema. En el caso de los
métodos podría ser aplicando los métodos a casos reales y
así verificando las
propiedades de los mismos.
3. Métodos Informales: expertos observan el sistema (o
el método).
4. Métodos formales: técnicas que formalizan el
proceso de evaluación.
A esta altura si es conveniente incluir una noción de los
siguientes puntos
• Riesgo de no evaluarla : cada característica
debe tener una razón de ser y el riesgo de no tenerla en
cuenta debe estar claramente identificado. Por ejemplo no
evaluar cierta característica puede hacer que el sitio no
soporte cierta cantidad de usuarios. También puede hacer
que los tiempos de desarrollo se extiendan por no tener
este punto en cuenta.
• Beneficios de Evaluarla : de igual manera debe
existir alguna justificación que abogue por la inclusión de
dicha característica. Se sugiere documentarla para poder
argumentar sobre su inclusion en un proyecto en
particular.
• Impacto en tiempos y costos de su evaluación:
elegir incluir una característica como parte del plan de
calidad no es gratis. El costo se traduce en el tiempo de
desarrollo de la aplicación que se incrementarán por
considerar y evaluar dicha característica. A diferencia de
los riesgos que pueden hacer que el los tiempos se
incrementen de forma impredecible, este punto busca
definir un incremento de tiempo del proyecto de modo
que justifiquen los beneficios, minimicen los riesgos y
aumente la predicibilidad.
A continuación se resumen en un cuadro en un ejemplo
de las distinton puntos a tener en cuenta a la hora de
definir una característica
Característica Paginas livianas
Codigo [Completar]
Nombre Corto Paginas livianas
Descripcion Definir el tamaño máximo que
debe ocupar cada página
Alcance Cada pagina del sitio
Status Definir si es obligatoria o
deseable
Forma de Evaluar [Completar]
Responsible Cumplirla [Completar] Otra plantilla se completará con las páginas web que
Responsible Evaluarla [Completar] contendrá el sitio
Cuando Cumplirla [Competar]
Ponderación Entre 0 y 1 Página Campo Template
Beneficio de Evaluarla Se aseguran que cada página <Página 1>
sea liviana y no cargue rápido <Página 2>
en el cliente …
Riesgo de no evaluarla Se pueden generar páginas muy <Página
pesadas que afecten la N>
performance de la aplicación Planilla de las páginas de la aplicación
Impacto en tiempos y Estimacion un 5% más de
costos tiempo y un 5% más de costos Dicha plantilla se utilizará como herramienta para
en el desarrollo de cada página evaluar ciertas características. Por ejemplo si una
Posible definición de una caracteristica característica a evaluar es que cada página de nuestra
aplicación debe pesar menos de 100K, esta plantilla nos
Para algunos puntos a completar, como por ejemplo la servirá como herramienta.
forma de evaluar y cuando cumplirla, si bien su Esta plantilla tambien nos permite diferenciar
implementación dependerá del sitio en particular, resultará características según la página. Indicar cosas como: la
útil definir distintas alternativas para facilitar la aplicación home de nuestro sitio debe pesar menos de 100K, no
del template. obstante el resto de las páginas deben pesar menos de
1000K.
3.4. Elementos del template Cabe aclarar que el template define esta grilla pero no su
contenido. Es el momento en el que se adapata a un sitio
Basándose en el marco conceptual descripto en la en particular cuando se deberá completar su contenido
sección 2, y haciendo una adaptación del mismo, el reemplazando página n por el nombre de la página real de
template agrupa las distintas características a evaluar en la aplicación.
las siguientes secciones: Otra plantilla interna sera la de navegación o contraste
• Estructura entre páginas
• Temporal
• Usabilidad
• Calidad Interna <Página 1> <Pagina 2> … <Pag. N>
<Página 1> ------------
Para cada sección se estudiará más adelante puntos <Página 2> ------------
técnicos concretos que se sugieren incluir en el template. …
<Pág. n> ------------
Plantilla de navegación o contraste
3.5. Plantillas Internas
Es una herramienta que se utilizará para evaluar aquellas
El template define las una serie de plantillas internas. La características, como la navegabilidad del sitio, que
primer plantilla define las características generales que dependen de más de una página.
tendrá el sitio. Contiene aquellas que influirán en la Por ejemplo para evaluar la característica de que el
evaluación de la calidad del mismo. usuario debe tener una forma en cualquier momento de
navegar a la home del sitio.
Característica Valor
Entorno Intranet / Internet 3.6. Variables
Tipo de Aplicación Webcomerce,
Educacion, En conjunto con las plantillas internas, el template define
Portal… ciertas variables que deben recibir un valor a la hora de
Usuario Final … derivar del template un plan de calidad como se verá más
Vel. Prom. Conexión Usuario Final aadelante.
Usuarios Concurrentes a Soportar Para aquellas variables que se enuncian de la forma para
Tecnología .NET / Java / Php cada página debe utilizar la plantilla de las páginas de la
Planilla de las características generales del sitio
aplicacion para definir su valor dependiendo de la página
de nuestro sitio web.
Las variables que se definen en el template son
• <TIEMPO_ACTUALIZACION> : Para cada
página de nuestro sitio se definen cada cuanto tiempo se
espera que su contenido se actualice.
• <TIEMPO_RESPUESTA> : Para cada página se
define en cuanto tiempo se espera renderice el contenido
al usuario final
• <PESO DE CADA PAGINA> : Para cada página
se define el peso máximo que debe tener
• <CANTIDAD REQUESTS> : Para cada página
define la cantidad máxima de requests que debe realizar
Las variables por si sola no hacen nada sino que sirven
como input a aquellas características que las utilicen.
4. Estructura del template
Basándonos en la estructura del template propuesta se
estudiarán a continuación una guia de buenas prácticas,
técnicas y sugerencias a incluir como parte del template.
4.1. Estructura del sitio : links
Jackob Nielsen [3] define una guía de como mostrar los
links en una página web. A pesar de algunas excepciones
sugiere que los links siempre estén coloreados y
subrayados para mejorar la percepción del usuario de que
allí es donde se puede hacer click.
En la siguietne tabla se resumen aquellos puntos a tener
en cuenta de los links de la aplicación:
Si No
Funcionan los links
Se marcan con otro color los
links visitados
Los links estan subrayados
Evita usar imágenes como links
Resumen de las características que tienen que ver con
links a evaluar
La major forma de asegurarse que los puntos anteriores
se cumplan es utilizando el tag <a> para los links en lugar
de botones e imagines: muchos desarrollos los utilizan en
forma incorrecta como reemplazo de los links.
4.2.. Estructura del sitio : css
Las hojas de estilo son una forma elegante de separa la
presentación del contenido en nuestro sitio. Como tal su
uso se encuentra ampliamente recomendado y
estandarizado hoy en día. Los css son una reomendación
de la w3c.
El uso de los css viene acompañado de unas
recomendaciones básicas. La primera de todas es que las
hojas de estilo sean válidas, es decir, que respeten el
estandar.
Una manera de verificar la validez de las hojas de estilo
es utilizar el validador online de la W3C [11].
Otra sugerencia es que las hojas de estilo se incluyan al
principio de la página para evitar problemas de
renderizados progresivos. Esto ocurre cuando primero se
muestra el contenido y, una vez que el usuario lo pudo
visualizar, se le applica el estilo produciendo un efecto
poco agradable.
Se sugiere tambien que los archivos CSS sean externos
para failitar la mantenibilidad y que esten minimificados.
Este es un proceso al cual se somete un archivo de texto y
mediante el cual se eliminan caracteres redundantes,
espacios y comentarios, haciendo que el archivo ocupe
mucho menos espacio.
Si a esto le sumamos la posibilidad de comprimir el
archivo de estilos mediante el algoritmo gzip, se
disminuirá mucho su tamaño y por lo tanto el tiempo que
tarde en transmitirse a través de la red.
A continuación se resumen aquellos elementos de css a
evaluar:
Si No
Utiliza CSS
El CSS es válido
El CSS está al principio de la
página (YL)
Hay elementos en el html que
deberían definirse en el css
El Css está mimificado
El Css está gzipeado
Evita expresiones css
El Css esta en un archivo
esterno
Usar una sola hoja de estilo para
todos las paginas del sitio
Resumen de las características que tienen que ver con
hojas de estilo a evaluar
El punto complicado de esto es asegurar que las hojas
de estilo se utilicen correctamente y que todo lo que tenga
que ver con la presentación se describa en ellas. Si el
color de fondo de un elemento html se define en el tag del
elemento y no mediante estilos por más que tengamos un
archivo de estilos no lo estaremos utilizando
correctamente.
 Es conveniente que para todo el sitio exista un solo
archivo de estilos que compartan todas las páginas y, de
esa forma, asegurar la consistencia a travéz del sitio.
Las expresiones css son un elemento de las hojas de
estilo cuyo uso se recomienda ser evitado
4.3. Estructura del sitio : javascript
Es sabido que el javascript es una fuente de errors y por
lo tanto cuanto menos abusemos de esa herramienta mejor
sera. Hoy en día, más aún con el advenimiento de las RIA
y AJAX, cada vez se usa más este lenguaje.
Como reomendación en este aspecto podemos sugerir
evitar tener javscripts duplicados y ponerlos al final para
que la pagina se renderice lo antes possible.
Las mismas recomendaciones de mimificación y
compression mediante el algoritmo gzip aplican a los
archivos javascript.
Recordar que los navegadores de internet no suelen
paralelizar mucho la bajada de los javascript y es por ello
que ultimamente se estan popularizando mucho técnicas
para bajar el javascript [21] de forma dinámica que
proven un grado mucho mayor de paralelización.
4.4. Estructura del sitio : html
Si desarrollamos una aplicación web vamos a tener que
lidiar en mayor y menor medida con el lenguaje html.
Definir de que manera vamos a utilizar dicho lenguaje
puede aportar mucho a la calidad del producto.
Como primera medida se recomienda definir un estandar
de identación y documentación del html de modo de
facilitar la lectura y mantenibilidad del mismo.
Un error muy comúm que se observa en las páginas web
es evitar poner el tag <title> dentro de la cabecera de la
página.
Los primeros sitios solían definir el layout mediante el
componente table. Hoy en día, con la incorporación de las
hojas de estilo, se estan dejando de usar dicho
componente para pasar a definir el layout de la página
mediante divs y css. De esta manera se logra una
flexibilidad mucho mayor.
Una forma muy utilizada para definir el layout fueron los
frames y los iframes. La experiencia mostró que dichos
components trajeron bastantes problemas. Por ejemplo la
posibilidad de agregar una página a favoritos y el
funcionamiento de los botones adelante y atras del
navegador. Por esas razones su uso se encuentran
desaconsejados.
Otras recomendaciones son utilizar tags semánticos,
aquellos como em, h1, h2, que definen el objetivo del
texto pero delegan en navegador y las hojas de estilo la
decisión de como renderizar dichos elementos.
En cuanto a las dimensiónes de los elementos html, se
recomeinda escribirlas como porcentajes en lugar de
unidades fijas.
Para las imagines hay dos recomendaciones: definir el
atributo alt para el contenido alternativo y evitar escalar
imagines para hacerlas más chicas. Asi se se puede
optimizar el uso de la red.
A continuación se resumen las características descriptas:
Si No
Todas las páginas definen el tag
<TITLE>
Evita el uso del componente
TABLE y utiliza DIV + css en su
lugar
Valida como xhtml
Evita el uso de los frames
Evita el uso de los iframes
Utiliza tags semanticos
Las dimensiones se escriben en
porcentajes en lugar de pixels u
otra escala
Las imagenes definen el tag alt
con contenido alternativo
Evitar escalar imagenes mas
chicas
El html esta identado de acuerdo
al estandar definido
Resumen de las características que tienen que ver con
html a evaluar
4.5. Temporal
Temporal. Cubre aspectos de calidad que tienen que ver
con alguna variable temporal. Se subdivide en dos
subsecciones: Actualizaciones por un lado y
Performance y tiempo de respuestas por el otro.
4.5.1. Actualizaciones
La frecuencia con la que se actualice el contenido de la
página y el porcentaje del tiempo que la misma debe estar
disponible online son dos variables importantes de
identificar.
Si la página se actualiza seguido es possible que
debamos considerar el algún mecanismo mediante el cual
los usuarios finales se enteren de las actualizaciones. Las
subscripciones ya sea para recibir las novedades o a los
feeds rss suelen ser una alternatica muy utilizada.
Junto con el contenido actualizado viene la forma de que
el usuario identifique rápidamente el contenido nuevo y lo
diferencie de aquel permanente y menos volatil.
El porcentaje del tiempo que nuestra página debe estar
online disponible es un dato que hay que tener en cuenta.
 Una página que esté el 99% del tiempo disponible debe
ser sustentada por una arquitectura que lo soporte.
Resolver ese problema dista mucho de ser trivial.
4.5.2. Performance y Tiempo de Respuesta
La performance de un sitio web es un tema muy amplio.
En principio nos centraremos en cuanto tiempo tarda en
responder el sitio a una accion del usuario y cuanto
tiempo tarda en cargar una página.
Para el primer caso el usuario espera un feedback
inmediato que su petición esta siendo procesada y es aqui
donde ajax trata de dar una solución.
Para el segundo podemos aplicar una serie de técnicas
que apuntan a un uso más eficiente de la red.
Steve Souders [14] propone en su libro High
Performance Web Sites un conjunto de 13 técnicas para
mejorar la performance de un sitio web.
Para evaluar dichas técnicas se puede incorporar una
herramienta llamada YSlow [15] que funciona junto con
el Firebug [16], un plugin del navegador Firefox.
Ventana de evaluación del YSlow
Se sugiere incluir la evaluación de dichas tecnicas con la
herramienta YSlow como parte del template propuesto.
Otro tema que consideraremos como parte de la
performance es como manejar la escalabilidad de la
aplicación agregando más servidores. Una opción
generalmente utilizada es poner un load balancer que
dividan el trabajo entre dos o más computadoras.
Como cada característica del template deve evaluar con
un valor entre 0 y 100 se toma la siguiente referencia para
convertir entre valores del YSlow y valores esperados por
el template
Valor YSlow Valor Evaluacion
A 100
B 80
C 60
D 40
E 20
F 0
Conversion entre valores del YSlow y del template
4.5.3. Usuarios Concurrentes
Otra medida que impacta en la performance es el tráfico
al que somete la aplicación web y como se degrada la
performance a medida que crece la cantidad de usuarios
concurrentes.
En este aspecto se sugiere que la plantilla contemple un
estimado de visitas por período de tiempo y un numero de
usuarios simultáneos que la aplicación debe soportar antes
de que se degrade la performance.
Dichos valores deben ir acompañados de un plan de
contingencia que defina como proceder ante un aumento
imprevisto de la demada.
La velocidad de conexión del usuario final es otro factor
a considerar. Lamentablemente muchas veces no se puede
determinar de antemano.
La estimación del tiempo, para que sea lo más precisa
possible, debe diferenciarse por cada página web. No es el
mismo tráfico el esperado para la home de nuestro sitio
que para otro tipo de página.
Analizar cuales son las páginas más visitadas una ves
implantada nuestra aplicación puede servirnos para
mejorar nuestras estimaciones iniciales.
Una vez relevados los valores de tráfico esperado
debemos darles su uso. Estos tiempos dependerán en gran
medida de tres factores.
1) Velocidad de conexión del usuario final
2) Distancia del usuario final y el lugar del sitio
3) Hardware donde esta alojado el sitio
4) Diseño de la aplicación
Para el primer punto debemos asumir una velocidad
media de conexión de nuestros usuario final como
hipótesis y en lo possible utilizarla como referencia a la
hora de realizar los sucesivos test de performance,
Una vez que el sitio se encuentre en producción
podemos mejorar nuestra hipótesis original en base a
mediciones que realicemos sobre el tráfico.
El segundo punto tendrá impacto directo en la cantidad
de saltos que deberán realizar los paquetes tcp/ip para
llegar a destino. Se recomienda hostear nuestro sitio en un
lugar cercano geograficamente a nuestros usuarios finales
y en el caso de ser un sitio con un alcance geográfico
mayor utilizar CDN (Content Delivery Networks) o
mirrors del sitio.
Una medición del trafico recibido también pude
ayudarnos a entender desde donde se acceder
geograficamente a nuestro sitio
El tercer punto icluira una descripción del harware donde
estará alojado el sitio y evaluará la presencia de load
balancers para distribuir la carga.
Los primeros tres puntos tratados deberían servirnos de
referencia para el cuarto. Este tendrá un impacto directo
en el desarrollo de la aplicación.
4.5.4. Medir la performance
La recomendación primero es medir como se comporta
el sitio con páginas estáticas de distinto peso. El template
puede incluir distintas páginas de prueba para realizar
mediciones basicas. Por ejemplo se puede tener páginas
html de 1K, 100K, 1000K de prueba y además probar
distintas combinaciones con javascript y hojas de estilo.
Dichas páginas son necesarias para tener una base de
referencia. También sirven como una aproximación para
definir el peso en bytes y características mínimas que
deben tener de cada página para satisfacer los
requerimientos de tráfico definidos.
Para medir necesitamos herramientas. Load Impact [19]
es una herramienta gratuita muy util para tal fin. A
continuación podemos ver un ejemplo de un gráfico que
genera.
Ejemplo de gráfico generado con la herramienta load
impact
Cabe aclarar que la versión gratuita nos similará hasta 50
usuarios finales mientras que si queremos una evaluación
mas exhaustiva debemos recurrir a la versión paga.
Una vez que midamos nuestras páginas de referencia
podemos aplicar las mediciones a nuestro sitio web.
Un problema que presentan las mediciones es que para
una grán cantidad de usuarios concurrentes son calculus
que demoran bastante tiempo en realizarse y por lo tanto
se hace dificil incluirlos como parte de la integración
continua.
4.6. Usabilidad
La usabilidad es un atributo de calidad que define cuan
facil son de usar las interfaces de usuario [4] de nuestro
sitio web. Mide cuán facil es de usar, cuan intuitiva y facil
de entender entender y aprender es el usa y de la
aplicación Web.
El problema de la usabilidad radica en la dificultad de
evaluar si un sitio es usable o no ya que no es algo fácil de
medir. Muchas veces se recurre a realizar test de
usabilidad.
Debido al alcance de las aplicaciones web, muchas veces
no se sabe cual va a ser el usuario final de las mismas.
Esto dificulta aún más la tarea.
Un desafío que se nos presenta es el del tema de la
accesibilidad y de como hacer nuestro sitio fácil de usar a
personas mayores, con problemas visuales.
Debido a la dificultad que presenta evaluar la usabilidad
de la aplicación, el template puede definir algunos
aspectos concretos que mejoran la usabilidad de un sitio.
Jakob Nielsen [17] estudia en profundidad el tema de la
usabilidad y en su sitio web se puede encontrar mucha
información al respecto del tema.
El template sugiere atacar el problema de la usabilidad
desde varios aspectos. Se divide en varias subsecciones:
objetivo, navegación, accesibilidad, proceso, diseño,
multiresolucion, multibrowser
4.6.1. Objetivo
Esta sección del template apunta a responder una
pregunta concreta. El usuario final, al ver una aplicación
web o al ver una página específica de un sitio, ¿sabe para
que sirve?
4.6.2. Navegación
En cuanto a navegación, el usuario final de la aplicación
debe poder responder en cualquier instante mientras esté
utilizando la aplicación :
• ¿Dónde estoy?
• ¿De dónde vine?
• ¿Dónde puedo ir?
Para responder a la primer pregunta debe poder
identificarse claramente cual es la página donde el usuario
está parado. Las páginas que no tienen un título
claramente definido o cuyo contenido es confuso son un
claro ejemplo de aquellas en las cuales al usuario no le
queda bien claro donde está parado.
 El uso de breadcrumbs como herramienta visual puede
aportar mucho a saber de donde viene el usuario mientras
que un esquema de navegación claro y facil de entender
puede responderle al usuario a donde puede ir.
En este ultimo aspecto es importante que esten
claramente direrenciado los contenidos de navegacion de
los contenidos dinámicos y los estáticos.
Para facilitar la escaneabilidad una sugerencias es incluir
encabezados que permitan ubicar rapidamente lo que uno
busca.
El uso de los scrolls merece un apartado especial. Segun
estudios realizados[4] los usuarios no se llevan nada bien
con los scroll horizontales por lo que su uso se
recomienda ser evitado.
Evita Scroll Vertical es un punto deseable ya que es
mejor que de un vistazo se pueda ver toda la información
disponible, aunque estudios realizados [4] muestran que el
usuario final hoy en dia es más propenso a aceptar el uso
del scroll vertical
Un punto si a tener en cuenta es no utilizar scrolls
interno dentro de scrolls. La presenia de varios scrolls
confunde al usuario
4.6.3. Accesibilidad
El término accesibilidad en aplicaciones web se refiere a
que personas mayores o condiscapacidades puedan
comprender, aprender, navegar y usar nuestro sitio web.
En la siguiente tabla se resumen los trastornos más
communes que pueden afectar la forma de que el usuario
final percibe nuestra página web.
• Visión
o seguera
o vision reducida
o daltonismo
• Audicion
o Sordera
o Disminución del rango auditivo
• Trastornos físicos y motores
• Trastornos del habla
• Trastornos neurológicos y cognigtivos
o Dislexia
o Desorden de atencion
o Poca memoria de corto plazo
• Trastornos relacionados con la edad
La Web Accessibility Initiative (WAI) [18] del World
Wide Web Consortium (W3C) resume gran cantidad de
recursos de como hacer la web accesible.
4.6.4. Proceso
Este punto del template define como se tendrá en
cuenta los aspectos de usabilidad como parte activa del
proceso de desarrollo.
Para ello se sugiere que exista un diseñador gráfico o
experto en usabilidad que pueda participar del proyecto.
Cuanto más esté involucrado dicha persona en el
proyecto, mejor sera siendo lo óptimo que se trate de un
integrante activo del equipo que lleva adelante el
proyecto.
Se sugiere [4] que para evaluar la usabilidad se realicen
prototipos o boquejos de las páginas del sitio web y los
mismos se validen con los clientes y usuarios finales para
ver si los mismos se sienten a gusto con el diseño y el
esquema de navegación
4.6.5.Diseño
Tener algunos items a considerar sobre el diseño de la
página servirá para poder evaluar el el prototipo visual del
diseñador.
Algunas sugerencias concretas consisten en tener
siempre una página de error personalizada, no abusar de
los gráficos, verificar que todos los controles en una
misma columna tengan el mismo ancho y evitar todos los
elementos del diseño que estén de más.
Si en la página hay mucho para leer los tectos de lectura
deben ser anchos y tener un contraste que facilite su
lectura. En general el contraste Negro-Blanco es el que
mejor funciona.
La aplicación debe presentar un look and feel consistente
a traves de toda la aplicación.
4.6.6.Multiresolucion
Ultimamente los usuario usan cada ves resoluciones más
altas. La ventaja que tiene que se puede mostrar más
información en una página. La desventaja que se suele
asumir que la aplicación se verá con una resolución
determinada y se crearan sitios que dificultan su lectua en
resoluciones superiors o inferiors a las que fueron
desarrollados.
Se sugiere que al desarrolar el sitio se tengan en cuenta
distintas resoluciones posibles y que el contenido
mostrado sea escalable independiente de la misma.
 4.8. Calidad Interna
La calidad interna amide aquello que el usuario de la
aplicacion no ve. La ISO 9126 define que la calidad
Más Alto interna del equipo del trabajo y del proceso influenciará la
1024x768 calidad interna del producto. Esto se traducirá en una
800x600 major calidad percidida el usuario.
En particular hablaremos de la calidad interna en cuanto
640x480
al equipo de desarrollo y el producto en si.
Desconocido

4.8.1. Del equipo

Mide aspectos que tienen que ver con el equipo y su

4.6.7.Multibrowser
Hoy en día el mercado ofrece una gran cantidad de
navegadores de internet. Si pretendemos ampliar el
alcance de un sitio, ignorar un navegador seria darle la
espalda a una gran cantidad de los usuarios finales que los
usan.
Los navegadores más usados hoy en dia son Internet
Explorer 5, Internet Explorer 6, Internet Explorer 7,
Internet Explorer 8, Mozilla, Netscape, Firefox, Opera,
Safari y Chrome.
A continuación se muestra el porcentaje uso de cada
explorador segun [18] w3schols
forma de trabajar. Cubre aspectos como control de
versions, metodologías utilizadas, metodos para evaluar la
calidad.
Un aspecto importante en el que se hace incapié es el del
ambiente de integración continua ya que, como se
menciono en su momento, muchas características
definidas en el template pueden ser evaluadas en forma
automatica de esa manera.
Para mejorar la integración de los Fuentes generados
por el equipo de desarrollo. y como requisito para
implementar un ambiente de integración continua, de
requiere tener un repositorio de control de versions. Los
repositories mas utilizados hoy en día son el CVS, el SVN
y el SubVersion.
Como se mencionará mas adelante, buena parte de la
productividad del equipo sera dadá por la adopción del el
uso de los unit test y los test de regression como parte de
un proceso de integración continua.
Es una recomendadión tener ambientes de producción y
pruebas separados

IE7
4.8.2. Del producto
IE6
IE8 Va directamente al código fuente de la aplicación y trata
FireFox temas sobre estilos de codificación, arquitectura de la
Chrome aplicación y documentación
Safari
En un equipo heterogeneo de programadores es útil
definir de antemano estándares de codificación y hacer
Opera
reviews de código para verificar que dichos estándares se
cumplan
Una herramienta muy útil son los unit tests. De la mano
de los unit test se pueden calcular la cobertura de código
Porcentaje de uso segun navegador a Febrero del 2009 de forma de saber que porcentaje de nuestro código esta
Fuente w3schols cubierto y testeado por unit test. El template de calidad
puede requerir que al implementarlo se definan rangos
Una forma de evaluar el funcionamiento en multibrowser deseables de cobertura de código.
es programar los test de regression para que sean Junto con los unit test otra herramienta muy util para
automatizados en distintos navegadores y de esa forma mejorar la calidad son los test de regression
asegurarse que funionan no solo para uno sino para todos En cuanto a la calidad del producto cuanto más compleja
los navegadores para los que se desean. sea la aplicación mayor sera la necesidad de definir una
arquitectura. Para las aplicaciones web se suele usar un Ponderación 1
estilo N-Layered. Beneficio de Evaluarla Se aseguran que cada
pagina sea liviana y no
5. Aplicar la plantilla a un desarrollo nuevo cargue rapido en el cliente
Riesgo de no evaluarla Se pueden generar paginas
A partir de la plantilla derivaremos lo que daremos en muy pesadas que afecten la
llamar el plan de calidad de un sitio web. Adoptaremos performance de la
ese nombre, si bien el concepto del plan de calidad aplicación
generalmente cubre más aspectos de los que tratamos en Impacto en tiempos y Estimacion un 5% mas de
este trabajo. costos tiempo y un 5% mas de
costos en el desarrollo de la
Para aplicar la plantilla a un desarrollo nuevo se deben pagina
definir los siguientes pasos
Derivar el plan de calidad a partir de la plantilla
1) Definir que caracteristicas definidas en el template significa adaptar la misma a un sitio web en particular.
van y cuales no van Esto es concensuar con el equipo técnico que
2) Definir las variables que dice la plantilla características del template resultan relevantes al la
3) Generar instancia de la plantilla o plan de calidad aplicacion web a evaluar/desarrollar y en que medida
Aplicar la plantilla a un desarrollo nuevo persigue los
Una vez generada la instancia de la plantilla a la que siguientes objetivos
llamaremos plan de calidad estaremos en condiciones de
aplicarlo a un sitio en particular 1) Concensuar la vision de calidad del sitio web
2) Tener una guia técnica que guie el desarrollo del
4) Aplicar instancia de la plantilla al desarrollo del sitio para los desarrolladores
proyecto 3) Ayudar a estumar major los tiempos
4) Ayudar a estimar major los costos
Una parte importante de la aplicación de la plantilla es 5)Tener un criterio uniforme con la diseñadora gráfica
utilizar el nuevo conocimiento adquirido y los temas de como debe entregar las cosas
nuevos que surgan y usarlos para agregar características
nuevas al template Para aplicar la plantilla diferenciaremos el caso que lo
No siempre va a ser possible cumplir con toddas Las hagamos a un sitio nuevo o para evaluar la calidad de un
características. Las mismas pueden ser deseables, sitio existente.
negociables u obligatorias.
A continuación se ve como quedaría la característica 2. Formas de aplicar la plantilla.
definida en el template una vez generado el plan de
calidad. La plantilla definida se puede aplicar de dos formas
distintas. La primera es para evaluar la calidad de una
Característica aplicación web existente. A esta forma la llamaremos
Codigo C01 forma reactiva de aplicar la plantilla.
Nombre Corto Paginas livianas
Descripcion Las paginas no deben
ocupar mas de 100K
Alcance Cada pagina del sitio
Status Obligatoria
Forma de Evaluar Un proceso parte del
ambiente de integracion
continua se encargará de
ver el tamaño de cada
pagina y decidirá si cumple
Responsible Cumplirla Desarrollador
Responsible Evaluarla Ambiente Integracion
Continua
Cuando Cumplirla Cada vez que se haga
commit
 La otra forma, a la que llamaremos proactiva, consiste
en utilizar la plantilla para concensuar de antemano
criterio de calidad a utilizar antes de desarrollar un sitio
web.
Ambas formas varían el objetivo para el que uno aplica la
plantilla
2. Uso Plantilla de calidad
La plantilal de calidad puede arrojar un valor entre 0 y
100 que sale de hacer un promedio ponderado del
resultado de la evaluación de cada característica indivisual
por su ponderación
Se pueden definir valores minimos y aceptables más allá
de definir que características son obligatorias.
4. Estimación
El plan de calidad generado puede ser utilizado para
mejorar la estimación de un proyecto. En los proyectos
web a veces es común que se le quite importancia a
ciertos temas que tienen que ver con la calidad y que se
mire todo desde la complejidad de la lógica de negocios
Es por ello que estimar el tiempo que va a llevar
realizar una aplicación web no es lo mismo que estimar
otro tipo de aplicaciones. En un equipo de desarrollo es
habitual que se dediquen horas a temas técnicos, por
ejemplo de algo que funciona en un explorador y en otro
no.
El plan de calidad ayuda bastante a estimar esto. A
continuación vemos como influye el tema de la calidad en
el triangulo de la negociación de administración de
proyectos.
Triangulo de la negociación
A este triángulo se le incluyó en el medio el concepto
de calidad Los lados del triangulo corresponden al
alcance, el tiempo y los recursos. De este triangulo se
pueden hacer lecturas del estilo: si lo quiero en un tiempo
fijo voy a tener que negociar los recursos necesarios y el
alcance que puedo cumplir.
Aqui estamos considerando al alcance más desde el
punto de vista de los requerimientos funcionales. Para
hacer más visible el tema de la calidad se la agregó como
una variable más a tener encuenta en las estimaciones.
Por ejemplo decir que una aplicación funcionará de
igual forma en todos los exploradores hará que el
desarrollo lleve más tiempo.
La plantilla pore sugiere documentar para cada
característica a observar de una aplicación web el impacto
que mantiene la misma y de esa forma utilizar la misma
como una herramienta para mejorar estimacion de los
costos y el tiempo que nos llevará realizar el proyecto.
6. Trabajos Futuros
El presente trabajo trata de la evaluación de la calidad
desde un punto de vista técnico. Se sugieren futuros
trabajos que realicen un template con cara al usuario final
y un mapeo entre distitnas caracteristicas no tecnicas de
ese template y las caracteristicas técnicas propuestas en
este template.
10. References
[1] Steve Souders Even Faster Websites: Essential
Knowledge for Frontend Engineers
[2] http://stevesouders.com/
[3] Jackob Nielsen, Guides for visualizing links,
http://www.useit.com/alertbox/20040510.html
[4] http://www.useit.com/
[5] http://htmlhelp.com/tools/valet/
[6] Magalí González, Silvia Abrahão, Joan Fons, Oscar [13] http://developer.yahoo.com/ypatterns/
Pastor, Evaluando la Calidad de Métodos para el Diseño
de [14] Steve Souders, High Performance Web Sites
Aplicaciones Web
[15] http://developer.yahoo.com/yslow/
[7] http://es.wikipedia.org/wiki/HTTP
[16] https://addons.mozilla.org/es-ES/firefox/addon/1843
[8]
http://es.wikipedia.org/wiki/Aplicaciones_de_Internet_Ric [17] http://www.useit.com/
as
[18]
[9] http://en.wikipedia.org/wiki/Software_quality http://www.w3schools.com/browsers/browsers_stats.asp

[19] http://www.w3.org/WAI/
[10] http://www.w3.org/TR/CSS2/
[20] http://loadimpact.com/
[11] http://jigsaw.w3.org/css-validator/
[21] http://sites.google.com/site/io/even-faster-web-sites
[12] Garzotto F., Mainetti L. and Paolini P. Hypermedia
Design, Analysis and Evaluation Issues, Comunication of [22] http://stevesouders.com/cuzillion/
the ACM, Vol. 38, Nro. 8, August 1995.