Suscríbete a DeepL Pro para poder traducir archivos
Más información disponible en www.DeepL.com/pro.
El razonamiento del diseño mejora la calidad del
diseño del software
Antony Tang1, Minh H. Tran1, Jun Han1 y Hans van Vliet2
1
Universidad Tecnológica de Swinburne, Melbourne, Australia
{atang,mtran,jhan}@ict.swin.edu.au
Universidad VU2, Amsterdam, Países Bajos
[email protected]
Resumen. La toma de decisiones justificables es un aspecto crítico del diseño
de la arquitectura del software. Sin embargo, la investigación empírica sobre los
efectos del razonamiento de diseño en la calidad del diseño de software ha sido
limitada. El objetivo de este trabajo es investigar si existe alguna mejora en la
calidad del diseño de software cuando se aplica el razonamiento de diseño.
Realizamos un estudio empírico en el que participaron veinte diseñadores, a los
que se les pidió que diseñaran una interfaz de usuario y sus diseños fueron
puntuados y comparados. Los resultados mostraron que el grupo de prueba al
que se le aplicó el razonamiento de diseño produjo un diseño de mayor calidad
que el grupo de control, especialmente en el caso de los diseñadores sin
experiencia.
Palabras clave: Razonamiento de diseño, diseño de arquitectura de software, usabilidad.
1 Introducción
Los diseñadores de software tienden a basar sus juicios en creencias previas e
intuiciones más que en un proceso de razonamiento lógico. Esta tendencia es común
al pensamiento humano y ha influido en el rendimiento del razonamiento y la toma de
decisiones de muchas personas [1]. En este artículo, demostramos que el diseño de
software está sujeto al mismo sesgo cognitivo y, por tanto, puede afectar a la calidad
de sus resultados. A través de un estudio empírico, demostramos que la calidad del
diseño puede mejorarse con un simple enfoque de razonamiento de diseño.
Investigaciones recientes, especialmente en el área de la arquitectura de software,
han demostrado que el razonamiento y la lógica del diseño son importantes [2]. El
razonamiento de diseño ayuda a los diseñadores a tomar decisiones justificables
modelando explícitamente el razonamiento de diseño como una entidad de primera
clase [3]. En estos métodos se tienen en cuenta los requisitos funcionales y de calidad,
y se utilizan técnicas de toma de decisiones como el análisis de compensación para
seleccionar la solución que mejor se adapte a los criterios de diseño. Se argumenta
que los fundamentos del diseño deben capturarse explícitamente, junto con las
decisiones tomadas y el diseño resultante. Constituyen el conocimiento arquitectónico
del software [4].
Esta investigación explora cómo el razonamiento de diseño afecta a la calidad del
resultado del diseño. Para explorar esta cuestión, hemos llevado a cabo un estudio
empírico con el atributo de calidad de la usabilidad. La usabilidad es un atributo de
calidad importante en la arquitectura del software [5, 6]. Se refiere a si los usuarios
son capaces de utilizar un sistema para realizar sus tareas de forma eficaz, eficiente y
con una experiencia satisfactoria.
Nuestra hipótesis es que, aplicando un proceso de razonamiento de diseño, los
diseñadores conseguirían una interfaz de usuario más usable. El estudio se realizó con
dos grupos de diseñadores que
S. Becker, F. Plasil y R. Reussner (Eds.): QoSA LNCS2008, pp5281,. 28- 42,2008.
© Springer-Verlag Berlin Heidelberg 2008
El razonamiento del diseño mejora la calidad del
diseño del software
29
tienen una experiencia de diseño similar. El grupo de control llevó a cabo el diseño
como lo hace habitualmente, mientras que el grupo de prueba realizó las tareas
utilizando un enfoque de razonamiento de diseño. Los resultados han demostrado que
el uso de un enfoque de razonamiento ha mejorado, por término medio, la calidad del
diseño. Especialmente para los diseñadores relativamente inexpertos, la mejora es
notable. Para ellos, el razonamiento del diseño proporciona un marco para la
deliberación y ayuda a construir y mantener una imagen mental del diseño en curso.
Los diseñadores experimentados tienen menos necesidad de esa ayuda, simplemente
"saben" cómo proceder [7].
El resto del artículo se organiza como sigue. En la sección se discuten2 los
conceptos de razonamiento de diseño y los trabajos relacionados con el razonamiento
de diseño de usabilidad. La sección 3 presenta el estudio empírico y los resultados. La
sección 4 analiza las lecciones que hemos aprendido al aplicar el razonamiento de
diseño al diseño de software. Concluimos el artículo en la sección 5.
2 Trabajos relacionados
2.1 Razonamiento del diseño
Los investigadores en psicología han propuesto que hay dos sistemas cognitivos
distintos que subyacen al razonamiento. El sistema 1 (sistema heurístico) comprende
un conjunto de subsistemas autónomos que incluyen tanto módulos de entrada innatos
como conocimientos específicos del dominio adquiridos por un mecanismo de
aprendizaje general del dominio. El sistema 2 (sistema analítico) permite razonar
según normas lógicas [1]. Juntos forman la teoría del proceso dual que explica el
"fracaso del pensamiento racional" de las personas cuando éstas se basan en gran
medida en creencias previas e intuiciones en lugar de en un proceso de razonamiento
lógico [8, 9]. Estas conclusiones también se confirman en un estudio más reciente
sobre la toma de decisiones en el diseño de software, en el que los diseñadores hacen
uso de tácticas de decisión racionales y naturalistas [10].
En el desarrollo de software, el razonamiento de diseño es un proceso importante
que los diseñadores utilizan para desarrollar una solución. Los diseñadores de la
industria del software suelen confiar en la intuición y la experiencia para tomar
decisiones de diseño. El inconveniente de este enfoque es que la calidad de las
decisiones depende en gran medida de la experiencia y los conocimientos de las
personas. Dado que los fundamentos del diseño desempeñan un papel importante en
la toma de decisiones de diseño [2, 11], es importante entender en qué consisten los
fundamentos del diseño para producir un buen diseño. Rittel y Webber [12] ven el
diseño como un proceso de negociación y deliberación. Sugieren que el diseño es un
"problema perverso" en el que no hay un conjunto bien definido de soluciones
potenciales, por lo que es importante que un diseñador aprenda a manejar y sopesar
alternativas.
Existen diferentes enfoques para el razonamiento del diseño. Uno de ellos es la
argumentación. La representación básica basada en la argumentación consiste en
utilizar nodos y enlaces para representar el conocimiento y las relaciones. Ejemplos
de este enfoque son QOC [13], DRL [14] y gIBIS [15]. Un segundo enfoque es
mediante el uso de plantillas de argumentación para capturar el razonamiento del
diseño. Este enfoque incorpora plantillas estándar en el proceso de diseño para
facilitar la captura del razonamiento de diseño. Este enfoque está orientado a la
aplicación práctica del razonamiento de diseño en la industria. Algunos ejemplos son
30
A. Tang et al.
Architecture Decision Description Template [16] y Views and Beyond [17]. Un tercer
enfoque es un híbrido de los dos primeros. Ejemplos de este enfoque son AREL
[18] y Archium [4].
El razonamiento del diseño mejora la calidad del
diseño del software
31
Fig. AREL1. - Un modelo de razonamiento de diseño
Aunque existen diferentes enfoques del razonamiento de diseño, los conceptos
presentados en AREL son comunes al pensamiento actual de la investigación [4, 19].
En el resto de esta sección, presentamos el modelo AREL, cuyos conceptos utilizamos
en el estudio empírico. En este modelo, hay tres elementos clave a tener en cuenta:
preocupaciones de diseño, decisiones de diseño y resultados de diseño (Fig. 1).
Las preocupaciones de diseño son las que motivan la creación de una solución de
diseño. Las preocupaciones de diseño son las causas por las que se toman las
decisiones de diseño. Una preocupación de diseño puede ser un requisito del sistema,
un objetivo empresarial, un atributo de calidad como la usabilidad, una circunstancia
que influye en un diseño o un componente de diseño existente que ejerce algunas
restricciones de diseño.
El diseñador toma una decisión de diseño cuando evalúa por qué se crea o se elige
un diseño concreto. Capturar este conocimiento es importante porque justifica el
diseño y explica las razones a aquellos que no tienen un conocimiento íntimo del
diseño: usuarios, probadores y mantenedores. La información clave que contienen las
decisiones de diseño son los problemas de diseño, las hipótesis de diseño, las
limitaciones de diseño y la justificación del diseño para la selección o el rechazo de
una opción de diseño. Los vínculos (Fig. 1) entre los problemas de diseño y las
decisiones de diseño indican qué problemas de diseño se tienen en cuenta en una
decisión. Los resultados de las decisiones de diseño, es decir, los resultados del
diseño, están vinculados a las decisiones de diseño porque los resultados son la
consecuencia de una decisión.
Los resultados del diseño son los resultados de una decisión de diseño: el diseño
elegido es el diseño que se ha seleccionado, y contiene los elementos de diseño como
los componentes, las clases y los esquemas de base de datos que se implementarían; el
diseño alternativo son las opciones de diseño que se han considerado pero que se han
rechazado. Capturar todas las opciones de diseño, incluyendo el diseño alternativo
rechazado, es importante por tres razones (a) una consideración exhaustiva de todas
las opciones disponibles muestra que el diseñador no ha omitido ninguna opción de
diseño viable; (b) documentar las opciones de diseño puede apoyar el retroceso del
diseño si una solución de diseño inicial es inviable cuando se consideran más detalles;
(c) la identificación de diferentes opciones de diseño permite realizar un análisis de
compensación de diseño para justificar la selección de la opción de diseño más
adecuada.
2.2 Usabilidad de la interfaz de usuario
La calidad de los diseños de interfaz de usuario se ha considerado un aspecto
importante de la arquitectura de software. Las investigaciones han demostrado que, en
el diseño de la interfaz de usuario, los diseñadores deben tomar decisiones sobre la
32
A. Tang et al.
selección de opciones de diseño de una u otra manera [20-24]. Sin embargo, los
modelos existentes del ciclo de vida del diseño de la interfaz de usuario proporcionan
directrices muy limitadas que ayudan a
El razonamiento del diseño mejora la calidad del
diseño del software
33
los diseñadores razonan sobre las opciones de diseño y toman decisiones de diseño
justificadas. El razonamiento del diseño de la interfaz de usuario es algo que siempre
se ha asumido y es intuitivo.
Estudios recientes han señalado que el resultado del diseño de la interfaz de usuario
incluye tanto la propia interfaz resultante como la justificación de por qué se elige
dicha interfaz. El estudio exploratorio de Howard [22] identifica elementos clave,
como el entorno, el enfoque y los agentes, que suelen tenerse en cuenta cuando los
diseñadores toman decisiones de compensación. El estudio de Howard también
modela un proceso de comportamiento en el que los diseñadores argumentan la
elección entre dos elementos clave. MacLean et al. [24] examinan una representación
de la racionalidad del diseño. Han desarrollado una notación semiformal que permite
a los diseñadores representar explícitamente las opciones de diseño y las razones para
elegir entre ellas. Sin embargo, hasta donde sabemos, no hay pruebas empíricas sobre
cómo el razonamiento de diseño influye en la calidad del diseño de la interfaz de
usuario.
3 Un estudio empírico
El objetivo de este estudio era explorar los efectos del razonamiento de diseño en la
calidad del mismo. Para ello, pedimos a los participantes que diseñaran una interfaz
de usuario para un sistema comercial. El caso se eligió cuidadosamente y se
simplificó para asegurarse de que tuviera sentido para los participantes y no fuera tan
sencillo como para diseñarlo sin consideraciones cuidadosas.
Hemos estado trabajando con una empresa de automoción para desarrollar un
sistema basado en la web para supervisar los vehículos de prueba de una flota. La
función principal del sistema es permitir a los ingenieros de automóviles supervisar las
señales electrónicas recogidas de las unidades de control electrónico (ECU) de un
vehículo. A través de una interfaz de usuario, un ingeniero puede preparar un
programa de supervisión que especifica la información que debe supervisarse. Cada
programa de monitorización debe contener un mínimo de 1 solicitud y un máximo de
99 solicitudes (es decir, el requisito R1). Los ingenieros buscan y seleccionan las
señales electrónicas de una lista de búsqueda de 1.700 señales al especificar las
solicitudes (es decir, el requisito R2). Una solicitud especifica qué señales electrónicas
deben ser monitorizadas y las condiciones de inicio y parada de la monitorización (es
decir, el requisito R3). Los participantes recibieron otros requisitos, como la inserción y
supresión de condiciones y señales de control, pero no los describimos aquí en detalle.
3.1 Participantes
El estudio cuenta con veinte participantes. Se utilizó un método de muestreo
conveniente para invitar a profesionales de la industria del software y del mundo
académico a participar en el estudio. Los participantes se distribuyeron aleatoriamente
en dos grupos: grupo de prueba y grupo de control. La experiencia media en diseño
del grupo de prueba y del grupo de control es de 8,95 años y años8.40,
respectivamente.
3.2 Procedimiento del experimento
Tanto al grupo de control como al de prueba se les pidió que diseñaran una interfaz de
usuario para el sistema de control. Los grupos recibieron lo siguiente: (a) un conjunto
de requisitos para el diseño; (b) requisitos de usabilidad; y (c) controles de la IU que
pueden utilizarse en el diseño. Realizamos el experimento con cada participante de
34
A. Tang et al.
forma individual.
El grupo de control llevó el diseño como lo hace habitualmente. Al grupo de
prueba se le informó sobre el proceso de razonamiento del diseño y se le pidió que
aplicara los principios de
El razonamiento del diseño mejora la calidad del
diseño del software
35
razonamiento de diseño. En las sesiones informativas, describimos los principios de
razonamiento de diseño de AREL sin hacer referencia a su modelo formal. Durante el
experimento, cuando los participantes llegaban a un punto de decisión de diseño,
tenían que explicar sus opciones y problemas de diseño, y justificar por qué habían
elegido una opción de diseño concreta frente a otras alternativas. Mientras los
participantes justificaban sus decisiones de diseño, los entrevistadores no daban
ninguna pista sobre cómo diseñar ni se dedicaban a discutir la calidad del diseño de
los participantes. Sin embargo, los entrevistadores hacían las siguientes preguntas
para asegurarse de que se aplicaba el razonamiento: "¿Cuáles son los problemas de la
decisión?" y "¿Cuáles son las opciones para resolver los problemas?".
Se pidió a los participantes, tanto del grupo de prueba como del de control, que
utilizaran un protocolo de pensamiento en voz alta [25] para describir sus estrategias
de diseño. Al final de la sesión de diseño, se entrevistó a los participantes para
conocer sus comentarios. En la entrevista, utilizamos la técnica de pensamiento en
voz alta retrospectivo (RTA) [26] para recoger los comentarios de los participantes
sobre sus propios diseños después de haber completado las tareas. Se cronometró cada
sesión de diseño, empezando por el momento en que los participantes comenzaron el
proceso de diseño hasta que lo completaron, excluyendo la sesión informativa y la
entrevista.
En el estudio se recogieron datos cuantitativos y cualitativos. Los datos
cuantitativos incluían detalles de la experiencia de los participantes, la duración de las
tareas, los niveles de satisfacción y confianza en sus propios diseños y las
puntuaciones de calidad de sus diseños. Los datos cualitativos se obtuvieron a partir
del proceso de pensamiento en voz alta de los participantes, nuestra evaluación del
diseño de los participantes, nuestra observación del proceso de diseño de los
participantes y los comentarios de los participantes.
3.3 Hallazgos
Analizamos los resultados de las pruebas desde tres perspectivas: la calidad de los
resultados del diseño, el proceso de diseño y las opiniones de los participantes.
3.3.1 Resultados del diseño
Con cada diseño de interfaz de usuario, evaluamos la calidad del diseño basándonos
en tres (de diez) heurísticas de diseño de interfaz de usuario propuestas por Nielsen
[27]: (a) consistencia; (b) flexibilidad; (c) accesibilidad. Por ejemplo, evaluamos la
coherencia del diseño inspeccionando si los participantes utilizaron los controles de la
IU (por ejemplo, barras de desplazamiento, botones) de forma coherente en todo el
diseño. Para el propósito de este estudio, hemos seleccionado sólo las tres heurísticas
de usabilidad más relevantes.
Para el diseño de cada participante, calificamos la usabilidad en función de la
heurística seleccionada. Para cada heurística, utilizamos una escala Likert de 5 puntos
que iba de 0 a 4, siendo 4 el mejor diseño. Así, la máxima puntuación de un diseño es
12 y la peor 0. El proceso de calificación se realizó comparando la conformidad de
cada diseño con la heurística. A la hora de puntuar los diseños, los puntuamos y
comparamos independientemente del grupo del que procedieran para garantizar que
las puntuaciones fueran coherentes e imparciales.
Nuestra hipótesis es que el grupo de prueba que dispone de razonamiento de diseño
producirá un diseño de mayor calidad que el grupo de control. Si m1 es la puntuación
media del grupo de prueba y m2 es la puntuación media del grupo de control, las
hipótesis son
36
A. Tang et al.
H0: m1 = m2
H1: m1 > m2
El razonamiento del diseño mejora la calidad del
diseño del software
37
Tabla de puntuaciones de calidad del diseño de los grupos de prueba 1.y de control
n
Puntuación
media
Grupo de prueba
10
9.10
Desviaci
ón
estándar
1.52
Grupo de control
10
7.10
1.91
Prueba de
Wilcoxon
p = 0.02
La hipótesis nula H0 afirma que la calidad del diseño de la interfaz de usuario
creada por el grupo de control es la misma que la del grupo de prueba. La puntuación
media del grupo de control es de 7,10 y la del grupo de prueba es de 9,10. La prueba
de Wilcoxon 1[28] de una cola muestra que existe una diferencia significativa en la
calidad del diseño entre los grupos de prueba y de control con p < 0,0252 (véase la
Tabla 1). Como la prueba de Wilcoxon de una cola es significativa, rechazamos la
hipótesis H 0y aceptamos la hipótesis alternativa H1.. La conclusión es que la
aplicación de un proceso de razonamiento de diseño ha mejorado la calidad del diseño
de la interfaz de usuario.
Para entender qué aspectos cualitativos del diseño son diferentes entre los dos
grupos, analizamos el diseño de cada participante. Hay dos aspectos clave del diseño
y ambos tienen que ver con la usabilidad:
• (R1) la restauración entre y el 1seguimiento de las 99solicitudes; y
• (R2) determinar cómo buscar la(s) señal(es) del vehículo 1700 y seleccionarla(s)
para el control y la activación del control.
Grupo de prueba. Todos los participantes del grupo de prueba utilizaron el enfoque
basado en la racionalidad para diseñar para los requisitos dados. Al diseñar para el
requisito R1, los participantes seleccionaron una pestaña desplazable o una lista
expandible situada en un lateral para mostrar y seleccionar una solicitud. Los
participantes habían considerado inicialmente diferentes opciones de diseño, como
una lista emergente, una lista-tabla en el centro de la página y una lista desplegable.
Estas opciones se descartaron después de que los participantes consideraran los
problemas de usabilidad como parte del proceso de razonamiento del diseño.
Al diseñar el requisito R2, todos los participantes, excepto uno del grupo de prueba,
utilizaron una ventana emergente para especificar las señales de control. Aunque los
participantes consideraron otras opciones de diseño, como una lista desplegable y un
botón de control, decidieron que sólo era viable una solución de compromiso. Esto se
debe a la combinación de restricciones que se presentan: espacio limitado en la
pantalla, la necesidad de copiar las señales especificadas en múltiples controles y los
programas reutilizables. Algunos participantes exploraron en detalle cada rama de una
opción y retrocedieron cuando las opciones se volvieron inviables. En general, todos
los participantes han creado un diseño similar. Han articulado cuestiones similares
relacionadas con la usabilidad. La mayoría ha identificado un conjunto similar de
opciones de diseño con pequeñas variaciones. Estas variaciones menores son la
colocación de controles como "botones" y "tablas".
Hubo una excepción en el grupo. Este diseño utilizaba un enfoque basado en
menús. Aunque la interfaz de usuario seguía siendo utilizable, no se ajustaba a la
heurística de diseño de interfaz de usuario de Nielsen y, por tanto, las puntuaciones de
este diseño eran más bajas.
1
La prueba de Wilcoxon es una prueba no paramétrica adecuada para comparar datos
38
2
A. Tang et al.
clasificados que no hace ninguna suposición sobre su distribución .
Hemos utilizado la prueba estándar de significación en Para la prueba de una 0.05.cola de H1 en
nuestro caso, la significación es de 0,025.
El razonamiento del diseño mejora la calidad del
diseño del software
39
Grupo de control. En comparación con el grupo de prueba, el grupo de control
produjo diseños mucho más diversos y menos utilizables. En primer lugar, en cuanto
al diseño de la interfaz de usuario para gestionar múltiples solicitudes (es decir, el
requisito R1), se propusieron cuatro variedades de diseño, a saber:
•
•
•
•
Una lista textual: Las solicitudes se organizan en forma de lista de
hipervínculos en un lado de la pantalla, mientras que en el resto de la pantalla
se muestran los detalles de una solicitud.
Iconos gráficos: Las solicitudes se representan como iconos gráficos
numerados del 1 al 99. En este diseño, se ocupa todo el espacio de la pantalla
para mostrar los iconos99.
Un cuadro de texto: No hay una lista que muestre un resumen de todas las
solicitudes. Los usuarios recuperan los detalles de una solicitud introduciendo
una identificación única de la solicitud en el cuadro de texto proporcionado.
Este diseño ahorra espacio en la pantalla, pero requiere que los usuarios
recuerden las identificaciones de todas las solicitudes.
Una lista desplegable: Una lista desplegable muestra todas las solicitudes. Este
diseño ahorra espacio en la pantalla, pero desplazarse por una larga lista de
solicitudes puede resultar incómodo.
Entre estas variaciones de diseño, sólo la lista textual es utilizable, y cuatro de cada
diez participantes del grupo de control terminaron con este diseño. En los otros seis
diseños en los que la usabilidad era baja, los participantes diseñaron para múltiples
solicitudes después de haber terminado de diseñar para una solicitud individual. En
estos casos, no reconsideraron si su diseño de solicitud individual se ajustaba a las
solicitudes múltiples.
En segundo lugar, para buscar y seleccionar señales que especifiquen una solicitud
(es decir, un requisito
R2), el grupo de control derivó en tres diseños discretos, incluyendo:
Ventana emergente: Los botones se incluyen en diferentes secciones de una
solicitud (por ejemplo, condición de inicio, lista de control y condición de
parada). Cuando los usuarios hacen clic en un botón, se muestra una ventana
emergente que permite a los usuarios seleccionar una o más señales para
añadirlas a una sección concreta de la solicitud.
• Páginas secuenciales: Los usuarios deben primero buscar y seleccionar la(s)
señal(es) que quieren vigilar, y pasar a diferentes páginas para pegar la
información.
• Ventanas con pestañas: Las pestañas se utilizan para proporcionar diferentes
funcionalidades. Por ejemplo, la primera pestaña muestra una cuadrícula de
todas las señales disponibles entre las que los usuarios pueden elegir, la
segunda pestaña muestra una lista de las señales seleccionadas por los usuarios,
y la tercera pestaña muestra las condiciones de inicio y parada de la
monitorización. Los usuarios hacen clic entre ellas para copiar la información
de las señales.
De estos tres diseños, el mecanismo de ventana emergente es el más adecuado para
el sistema, porque permite a los usuarios seleccionar señales con un mínimo de clics y
errores del ratón. Sólo cinco de cada diez participantes del grupo de control utilizaron
una ventana emergente como medio de búsqueda y selección de señales.
•
3.3.2 Experiencia de los diseñadores y calidad del diseño
40
A. Tang et al.
Utilizando las puntuaciones de calidad de los participantes del grupo de prueba y del
grupo de control, analizamos las relaciones entre sus puntuaciones de calidad y su
experiencia de diseño. Los resultados se muestran en la Fig. 2. Los diamantes sólidos
representan a los que utilizaron el razonamiento de diseño, y los cuadrados huecos a
los que no utilizaron el razonamiento de diseño.
Observamos que por encima de la marca de 5 años de experiencia, las
puntuaciones de calidad de los dos grupos son similares. La mayoría de las
puntuaciones se sitúan entre 8 y 10, con algunos valores atípicos. Sin embargo, hay
una notable diferencia de calidad entre los dos grupos de participantes
El razonamiento del diseño mejora la calidad del
diseño del software
41
12
10
C
ali
da
d
de
l
di
se
ño
8
Con DR
6
Sin DR
4
2
0
0
5
10
15
20
25
30
Años de experiencia
Fig. Puntuación de la 2.calidad del diseño y años de experiencia
con menos de 5 años de experiencia. La mayoría de los participantes del grupo de
control en esta categoría puntúa entre y 6y8, la mayoría del grupo de prueba en esta
categoría puntúa entre 8 y 10. Estos resultados indican que el razonamiento de diseño
ayuda a los diseñadores menos experimentados a diseñar mejor.
Es interesante observar que los dos diseñadores más experimentados no produjeron
los mejores diseños. Ambos entraron en el campo de la tecnología de la información
en la era de los sistemas de procesamiento por lotes, mucho antes de que las interfaces
gráficas de usuario (GUI) se convirtieran en un problema. Sus conocimientos de
diseño se formaron en esa época anterior a las interfaces gráficas, y parece que no han
cambiado mucho desde entonces. Así lo confirman sus acciones y pensamientos en
voz alta durante los experimentos.
3.3.3 Proceso de diseño
Comparamos el tiempo que los dos grupos tardaron en terminar sus tareas. Por
término medio, el grupo de prueba tardó 39,30 minutos y el grupo de control 29,40
minutos. La prueba de Wilcoxon no muestra diferencias significativas entre el tiempo
empleado por el grupo de prueba y el grupo de control con p > 0,05 (véase la Tabla
2). Esto significa que ambos grupos tardaron un tiempo similar en terminar sus tareas.
Tabla Diseño del grupo de prueba 2.y control Tiempo
n
Tiempo medio
(min)
Grupo de prueba
10
39.30
Desviaci
ón
estándar
10.86
Grupo de control
10
29.40
10.08
Prueba de
Wilcoxon
p = 0.113
Además, consideramos los procesos de diseño de los dos grupos, como se describe a
continuación.
Grupo de prueba. Durante el estudio, el grupo de prueba tuvo que exponer
explícitamente sus opciones de diseño y los problemas de diseño, y justificar por qué
habían tomado una decisión concreta en cada punto del diseño. Por ejemplo, cuando
42
A. Tang et al.
explicaron los problemas del
El razonamiento del diseño mejora la calidad del
diseño del software
43
diseño inicial, dirían algo así como "¿cómo organizo la interfaz de usuario para
mostrar 99 solicitudes cuando no se pueden mostrar todas al mismo tiempo?" o
"¿cómo copio los datos de la pantalla de búsqueda de señales de forma que sea fácil
de usar?" o "¿cuántos clics se necesitan para hacer el trabajo?". Contemplaron su
diseño inicial y razonaron sobre lo que podía y no podía hacer. En algunos casos, los
participantes creían que el diseño inicial era adecuado. Sin embargo, cuando los
participantes intentaron conscientemente encontrar más opciones de diseño, a menudo
se les ocurrieron diseños alternativos. Hubo muchos casos en los experimentos en los
que dichas alternativas se convirtieron en el diseño final. Sin embargo, hubo casos en
los que las alternativas de diseño ayudaron a reforzar que el diseño inicial era más
adecuado cuando todos los diseños alternativos parecían ser inferiores.
Tras verbalizar las cuestiones, los participantes del grupo de prueba parecían tener
una imagen mental de esas cuestiones. A menudo, los participantes consideraron
cómo estas cuestiones entran en conflicto o funcionan entre sí en el diseño. La
verbalización explícita de las cuestiones y opciones de diseño ayuda al proceso de
pensamiento cuando los participantes empezaron a formular opciones de diseño y a
dar marcha atrás cuando no se pueden resolver ciertas cuestiones de diseño. Por
ejemplo, uno de los participantes exploró primero la cuestión de diseño de la lista de
las 99 solicitudes y luego examinó la cuestión de la visualización y edición de una
sola solicitud, y finalmente la búsqueda de señales. En cada punto de decisión,
retrocedía para evaluar si las opciones de diseño elegidas funcionaban. Los
participantes en el grupo de prueba consideraron que este proceso de retroceso y
verificación de las opciones de diseño era bastante natural cuando se planteaban
explícitamente los problemas y las opciones.
Grupo de control. A los participantes del grupo de control no se les pidió que
expusieran los problemas de diseño y justificaran sus decisiones. Observamos
diferentes patrones de comportamiento de diseño en función de la experiencia de los
diseñadores. El primer patrón fue que el diseño inicial de la mayoría de los
participantes se convirtió en su diseño final, especialmente en el caso de los
diseñadores con menos experiencia. A diferencia del grupo de prueba, el enfoque de
diseño del grupo de control se basó en gran medida en su intuición y en su primera
impresión. Los participantes parecían ceñirse a sus diseños iniciales, a partir de los
cuales seguían diseñando en función de los requisitos adicionales. Después de cada
punto de decisión, los participantes inexpertos, especialmente, dedicaron pocos
esfuerzos a reevaluar las consecuencias de los cambios adicionales en el diseño
inicial.
El segundo patrón era que, aunque el grupo de control conocía las directrices de
usabilidad, la mayoría no tenía en cuenta los requisitos de usabilidad en cada punto de
decisión. Nos dimos cuenta de que los participantes hablaban de los requisitos de
usabilidad al principio, pero eran menos conscientes de ellos a medida que avanzaba
el diseño. Los diseñadores más experimentados de este grupo fueron la excepción.
3.3.4 Comentarios de los participantes
En las entrevistas de seguimiento tras la sesión de diseño, se pidió a todos los
participantes que comentaran dos cosas:
(a) "¿Cuáles son sus consideraciones clave para el diseño?"
(b) "¿Tienes algún comentario sobre el proceso de diseño que has llevado a cabo
en este ejercicio?"
En respuesta a la pregunta (a), todos los participantes del grupo de prueba
44
A. Tang et al.
mencionaron que la usabilidad de la interfaz de usuario era una cuestión clave debido
a la complejidad de los requisitos y
El razonamiento del diseño mejora la calidad del
diseño del software
45
el limitado espacio de la pantalla. La mayoría de los participantes dijeron que la
facilidad de uso y comprensión era otra cuestión clave y sostuvieron que había que
ofrecer un mínimo de clics al usuario y un mínimo de pantallas de interfaz de usuario.
Algunos de los participantes también consideraron que el diseño debía ser
reutilizable, sobre todo la función de búsqueda de señales.
Al igual que el grupo de prueba, los participantes del grupo de control también
comentaron que los requisitos de usabilidad eran fundamentales para su diseño. De
hecho, la lista de preocupaciones de usabilidad importantes extraída del grupo de
control era muy similar a la del grupo de prueba. La convergencia en los comentarios
de los participantes sobre la pregunta (a) indicaba que, aunque ambos grupos de
participantes eran conscientes de los requisitos de usabilidad, tenían enfoques muy
diferentes para abordarlos. A los participantes del grupo de prueba se les pidió que
expusieran explícitamente sus problemas y opciones de diseño, y sus diseños finales
fueron más coherentes y más usables. Mientras que en el grupo de control, los
participantes llevaron a cabo el diseño de la forma en que lo hacen normalmente, los
resultados entre los participantes fueron menos consistentes y mostraron un nivel
inadecuado de usabilidad.
En respuesta a la pregunta (b), algunos participantes del grupo de prueba
comentaron que las cuestiones de diseño bien planteadas les ayudaron a pensar en el
diseño. Nueve de los diez participantes de este grupo mencionaron que la exploración
de las opciones de diseño les había ayudado a diseñar. Cuando se les preguntó por
qué, la sugerencia general fue que las opciones de diseño les permitieron evaluar lo
que funcionaría y lo que no. En el grupo de control, los participantes sin experiencia
hicieron muy pocos comentarios sobre su proceso de diseño, mientras que los
diseñadores experimentados de este grupo pudieron describir su análisis de requisitos
y su proceso de diseño.
Una vez que los participantes completaron sus tareas, se les pidió que calificaran su
satisfacción con sus propios diseños, utilizando una escala Likert de siete puntos en la
que 1 es no satisfecho y 7 es totalmente satisfecho. El grupo de prueba obtuvo una
media de 5,7 y el grupo de control una media de 4,9. Cuando se preguntó a los
participantes por su grado de confianza en la facilidad de uso de su diseño, utilizando
una escala Likert de siete puntos en la que 1 es nada de confianza y 7 es plena
confianza, el grupo de prueba informó de una media de y5.1 el grupo de control de
una media de 5.5.
Aunque el grupo de prueba estaba más satisfecho con su diseño, estaba ligeramente
menos seguro de sí mismo que el grupo de control. No podemos ofrecer ninguna
explicación para este resultado, salvo mostrar que las diferencias entre las
valoraciones de los dos grupos son estadísticamente insignificantes. Los resultados de
la prueba de Wilcoxon muestran que no hay diferencias significativas entre las
valoraciones de los dos grupos en cuanto a la satisfacción o la confianza en su diseño,
p = y 0.142,p = respectivamente0.34. Este resultado muestra que los participantes de
ambos grupos tenían una confianza y una satisfacción similares con sus propios
diseños, a pesar de las diferencias en las cualidades del diseño (como se indica en el
apartado 3.3.1).
4 Discusión de los resultados
El objetivo principal de este estudio es analizar cómo influye el razonamiento de
diseño en la calidad del mismo. A partir de los resultados del experimento, hemos
46
A. Tang et al.
realizado una serie de observaciones sobre cómo los participantes abordaron el
diseño.
El razonamiento del diseño mejora la calidad del
diseño del software
47
4.1 Debates
Los participantes de ambos grupos estudiaron los requisitos y las directrices de
usabilidad antes de crear su diseño. Los análisis han demostrado que el grupo de
prueba ha producido diseños de interfaz de usuario de mayor calidad que el grupo de
control en general. A continuación se resumen las diferencias entre el grupo de prueba
y el grupo de control:
Conciencia de razonamiento. Al exponer la justificación del diseño, los participantes
del grupo de prueba han hecho explícito el razonamiento subyacente a sus diseños.
Este proceso de justificación impuesto hizo que los participantes fueran más
conscientes de si sus decisiones eran correctas. Por ejemplo, después de exponer los
problemas de usabilidad que les preocupaban, tuvieron que encontrar la manera de
asegurarse de que su diseño era razonable a la hora de tratar el problema de
usabilidad. Así, el grupo de prueba era más consciente de los requisitos de usabilidad
en el diseño en comparación con el grupo de control. Este resultado podría reflejar la
importancia del razonamiento de los requisitos de calidad en el diseño de la
arquitectura del software.
Además, el enfoque de razonamiento indujo a los participantes del grupo de prueba
a razonar explícitamente sobre su diseño de forma estructurada. Por lo tanto,
probablemente fueron más cuidadosos a la hora de evaluar sus soluciones para
proporcionar justificaciones razonables. Esto contrasta con los participantes del grupo
de control, que utilizaron sobre todo su intuición y sus conocimientos para diseñar. El
objetivo del grupo de control era completar el diseño y satisfacer los requisitos sin
tener que justificarlos.
Conciencia de usabilidad. Los participantes del grupo de prueba identificaron la
usabilidad como una cuestión clave que debía abordarse en el diseño, y volvieron a
tratar este tema constantemente en el proceso de razonamiento. Por otro lado, los
participantes del grupo de control tuvieron en cuenta la usabilidad en la primera parte
del estudio y luego fueron menos conscientes de ella hacia el final de la sesión de
diseño. Esto implica que un razonamiento de diseño explícito puede ayudar a que los
diseñadores sean conscientes de los requisitos de calidad a lo largo del proceso de
diseño.
Impresión inicial del diseño. Observamos que los participantes, tanto del grupo de
prueba como del de control, se formaron inicialmente impresiones sobre una solución
de diseño. Tras explorar los problemas y las opciones de diseño, los participantes del
grupo de prueba pueden cambiar las impresiones iniciales del diseño en función de su
razonamiento sobre el mismo. Por otro lado, la impresión inicial del diseño
desempeñó un papel más dominante en el grupo de control, especialmente en el caso
de los diseñadores sin experiencia, el diseño inicial a menudo se convirtió en su
diseño final. Este resultado indica que la impresión inicial del diseño puede ser
dominante, pero un enfoque de razonamiento ayudaría a los diseñadores a considerar
los problemas y las opciones de diseño con más detenimiento, lo que les permitiría
alejarse de la creencia dominante para llegar a un diseño más adecuado.
Retroceso en el diseño. Los participantes del grupo de prueba retrocedieron en su
diseño y reconsideraron sus decisiones previamente tomadas con mucha más
frecuencia que los del grupo de control. Sugerimos que esto se debe a que al grupo de
prueba se le pidió que expusiera explícitamente sus problemas, opciones y
fundamentos de diseño, y tales actos les obligaron a abordar las cuestiones expuestas,
logrando así un nivel de razonamiento de diseño sistemático. El grupo de control, en
48
A. Tang et al.
general, no reconsideró las decisiones tomadas previamente mientras construía su
diseño. Se abordaron los requisitos individuales, pero no se identificaron los
problemas que surgieron de los requisitos conflictivos.
El razonamiento del diseño mejora la calidad del
diseño del software
49
Nivel de satisfacción y calidad del diseño El nivel de satisfacción y el nivel de
confianza entre el grupo de prueba y el grupo de control no fueron significativamente
diferentes. Esto es así a pesar de que el grupo de prueba había llevado a cabo el
proceso de diseño de forma más exhaustiva y había producido diseños de mayor
calidad. Tampoco se observaron diferencias entre los diseñadores más y menos
experimentados. Los resultados han demostrado que el nivel de satisfacción y el nivel
de confianza de un diseñador en su diseño no son buenos indicadores de la calidad del
diseño.
Tiempo de diseño. No hay diferencias significativas entre el tiempo medio que tarda
el grupo de prueba y el grupo de control en completar sus tareas. Esto implica que el
esfuerzo (en términos de tiempo) empleado por el grupo de prueba no es
significativamente mayor que el del grupo de control. Por tanto, no hemos encontrado
pruebas que indiquen que el uso del razonamiento en el diseño añada una sobrecarga
significativa al proceso de diseño.
Nivel de experiencia y calidad del diseño. Hemos examinado la experiencia de
diseño de los dos grupos y hemos comprobado que son similares. Sin embargo, como
se muestra en la Tabla 1, el grupo de prueba obtuvo una media mejor que el grupo de
control. Esto se debe a las mayores puntuaciones obtenidas por los diseñadores menos
experimentados del grupo de prueba (véase la figura 2).
En el grupo de prueba, los resultados de diseño de los participantes con experiencia
(es decir, más de 5 años) y sin experiencia (es decir, igual o menos de años5) no
muestran mucha diferencia. Ambos produjeron diseños de buena calidad. Los
participantes sin experiencia tardaron de media más tiempo en completar su diseño. A
diferencia del grupo de prueba, en el grupo de control hay una diferencia observable
en la calidad del diseño entre los participantes con experiencia y sin ella. Dicho de
otro modo, en el grupo de participantes sin experiencia, los que utilizaron la lógica del
diseño obtuvieron mejores resultados que los que no lo hicieron (véase la figura 2).
Estos resultados sugieren que, al utilizar un enfoque de razonamiento de diseño, los
diseñadores menos experimentados podrían beneficiarse de él para lograr diseños de
mayor calidad. Todos los diseñadores, con y sin experiencia, recibieron la misma
información sobre los primeros principios de usabilidad. El razonamiento de diseño
ha ayudado a los diseñadores inexpertos del grupo de prueba a aplicar estos principios
con éxito y a conseguir lo que los diseñadores expertos pueden hacer por mera
experiencia, pero el razonamiento de diseño ha mostrado poca diferencia entre los
diseñadores experimentados de los dos grupos. Esto sugiere que los diseñadores
experimentados tienen las intuiciones y la perspicacia necesarias para buscar los
problemas y las opciones correctas, tal y como demostró [7].
4.2 Limitaciones
Este estudio experimental se basó en una muestra de veinte diseñadores con
experiencia industrial. Para encontrar a los participantes se utilizó un método de
muestreo conveniente, es decir, los participantes son las personas a las que tuvimos
acceso y no fueron seleccionadas al azar. El tamaño de la muestra en este estudio es
pequeño, por lo que existen limitaciones en las interpretaciones de los resultados.
A los participantes del grupo de prueba se les pidió explícitamente que expusieran
sus problemas de diseño, sus opciones de diseño y su razonamiento. Estos
recordatorios podrían haberles inducido a pensar más a fondo, por lo que se podría
argumentar que la presencia de los entrevistadores podría sesgar los resultados. Sin
embargo, los entrevistadores no dieron ninguna pista de diseño, y las decisiones de
50
A. Tang et al.
diseño fueron deliberadas enteramente por los participantes basándose en sus
conocimientos
El razonamiento del diseño mejora la calidad del
diseño del software
51
y de razonamiento. Por lo tanto, sostenemos que los resultados de las pruebas de los
experimentos son válidos.
En este tipo de estudios empíricos hay diferentes variables experimentales que no
pueden controlarse estrictamente, por ejemplo, la familiaridad de los participantes con
las tecnologías implicadas. Para superar esta limitación, analizamos cualitativamente
lo que los diseñadores han hecho y dicho sobre sus diseños para asegurarnos de que
estas variables no afectan a la validez de los resultados. En cuanto a la cuantificación
de las puntuaciones, la limitación es el sesgo que pueden introducir los investigadores.
Para superarlo, hemos cotejado todos los diseños para asegurarnos de que existe una
puntuación coherente en todos ellos.
5 Conclusiones
Recientes trabajos de investigación han argumentado que la representación explícita
del razonamiento de diseño es útil y puede conducir a mejores resultados de diseño.
Sin embargo, la investigación sobre el impacto del razonamiento del diseño en la
calidad del mismo ha sido limitada. Utilizando la usabilidad como atributo de calidad
de la arquitectura de software, hemos estudiado cómo influye el razonamiento de
diseño en la calidad del mismo, diferenciando especialmente entre diseñadores
experimentados y no experimentados.
Hemos utilizado un estudio empírico para examinar la calidad del diseño de dos
grupos de diseñadores, uno equipado con razonamiento de diseño y otro sin él. Los
resultados del experimento han demostrado estadísticamente que un enfoque de
razonamiento de diseño mejora la calidad del diseño.
Los diseñadores que razonan explícitamente sobre sus decisiones de diseño
producen, por término medio, mejores diseños. Además, el razonamiento sobre el
diseño parece ayudar a los diseñadores inexpertos más que a los experimentados. Los
diseñadores que no utilizan el razonamiento de diseño explícito producen resultados
diversos, y algunos de los diseños tienen una baja usabilidad, especialmente en el caso
de los diseñadores inexpertos. Por lo tanto, concluimos que el razonamiento de diseño
ayuda a los diseñadores inexpertos a aplicar mejor los primeros principios de diseño y
a ofrecer un mejor diseño, al proporcionarles un marco de deliberación y una imagen
mental del diseño en curso.
Estos hallazgos han proporcionado resultados empíricos alentadores que apoyan
una mayor investigación sobre la incorporación del razonamiento de diseño en el
proceso de diseño de la arquitectura de software.
Agradecimientos. Este trabajo ha sido financiado en parte por el Australian
Collaborative Research Centre for Advanced Automotive Technology y el Swinburne
University of Technology Visiting Professor Award Scheme 2008.
Referencias
1. De Neys, W.: Detección implícita de conflictos durante la toma de decisiones. En:
Proceedings of the Annual Conference of the Cognitive Science Society, vol. 29, pp. 209214 (2007)
2. Tang, A., Barbar, M.A., Gorton, I., Han, J.: Un estudio sobre la justificación del diseño de
la arquitectura. Journal of Systems and Software 79(12), 1792-1804 (2006)
52
A. Tang et al.
3. Bosch, J.: Arquitectura de software: El siguiente paso. En: Oquendo, F., Warboys, B.C.,
Morrison, R. (eds.) EWSA 2004. LNCS, vol. 3047, pp. 194-199. Springer, Heidelberg
(2004)
4. Jansen, A., Bosch, J.: La arquitectura de software como conjunto de decisiones de diseño
arquitectónico. En: Proceedings 5th IEEE/IFIP Working Conference on Software
Architecture, pp. 109-120 (2005)
5. Bass, L., John, B.E.: Linking usability to software architecture patterns through general
scenarios. The Journal of Systems and Software 66(3), 187-197 (2003)
6. Golden, E., John, B.E., Bass, L.: El valor de un patrón arquitectónico de apoyo a la
usabilidad en el diseño de la arquitectura del software: un experimento controlado. En:
Proceedings of the 27th International Conference on Software Engineering (ICSE 2005),
pp. 460-469 (2005)
7. Cross, N.: Creative Thinking by Expert Designers. The Journal of Design Research 4(3)
(2004)
8. Epstein, S.: Integración del inconsciente cognitivo y psicodinámico. American
Psychologists 709-72449, (1994)
9. Evans, J.S.: In two minds: dual-process accounts of reasoning. Trends in Cognitive
Sciences 7(10), 454-459 (2003)
10. Zannier, C., Chiasson, M., Maurer, F.: Un modelo de toma de decisiones de diseño basado
en resultados empíricos de entrevistas con diseñadores de software. Information and
Software Technology 49(6), 637-653 (2007)
11. Bratthall, L., Johansson, E., Regnell, B.: ¿Es vital la justificación del diseño para predecir
el impacto del cambio? - A Controlled Experiment on Software Architecture Evolution.
En: Second International Conference on Product Focused Software Process Improvement,
pp. 126-139 (2000)
12. Rittel, H.W.J., Webber, M.M.: Dilemas en una teoría general de la planificación. Policy
Sciences 4(2), 155-169 (1973)
13. Maclean, A., Young, R., Bellotti, V., Moran, T.: Preguntas, opciones y criterios:
Elementos del análisis del espacio de diseño. En: Moran, T., Carroll, J. (eds.) Design
Rationale - Concepts, Techniques, and Use, pp. 53-105. Lawrence Erlbaum, Mahwah
(1996)
14. Lee, J., Lai, K.: ¿Qué es la racionalidad del diseño? En: Moran, T., Carroll, J. (eds.)
Design Rationale - Concepts, Techniques, and Use, pp. 21-51. Lawrence Erlbaum,
Mahwah (1996)
15. Conklin, J., Begeman, M.: gIBIS: a hypertext tool for exploratory policy discussion. En:
Proceedings of the 1988 ACM conference on Computer-supported cooperative work, pp.
140-152 (1988)
16. Tyree, J., Akerman, A.: Decisiones de arquitectura: Desmitificando la arquitectura. IEEE
SOFTWARE 22(2), 19-27 (2005)
17. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., Stafford, J.:
Documenting Software Architectures: Views and Beyond. Addison-Wesley, Reading
(2002)
18. Tang, A., Jin, Y., Han, J.: Un modelo de arquitectura basado en la racionalidad para la
trazabilidad y el razonamiento del diseño. Journal of Systems and Software 80(6), 918-934
(2007)
19. Ali-Babar, M., Gorton, I., Jeffery, D.R.: Captura y uso del conocimiento de la arquitectura
de software para el desarrollo de software basado en la arquitectura. En: Proceedings of the
Quality Software International Conference (QSIC 2005), pp. 169-176 (2005)
20. Carroll, J.M., Rosson, M.B.: Una biblioteca de casos para la enseñanza de la ingeniería de
la usabilidad: Fundamentos del diseño, desarrollo y experiencia en el aula. Journal on
Educational Resources in Computing 5(1), 1-22 (2005)
El razonamiento del diseño mejora la calidad del
diseño del software
53
21. Mayhew, D.J.: The usability engineering lifecycle: a practioner's handbook for user
interface design. Morgan Kaufmann Publishers, San Francisco (1999)
22. Howard, S.: Trade-off decision making in user interface design. Behaviour & Information
Technology 16(2), 98-109 (1997)
23. Norman, D.A.: Principios de diseño para interfaces persona-ordenador. En: Proceedings of
the SIGCHI conference on Human Factors in Computing Systems, pp. 1-10. ACM Press,
Nueva York (1983)
24. MacLean, A., Young, R.M., Moran, T.P.: La justificación del diseño: el argumento detrás
del artefacto. En: Proceedings of the SIGCHI conference on Human factors in Computing
Systems, pp. 247-252. ACM Press, Nueva York (1989)
25. Erikson, T.D., Simon, H.A.: Análisis del protocolo: Verbal Report as Data. The MIT Press,
Cambridge (1985)
26. Guan, Z., Lee, S., Cuddihy, E., Ramey, J.: The validity of the stimulated retrospective
think-aloud method as measured by eye tracking. En: Proceedings of the SIGCHI
conference on Human Factors in Computing Systems, pp. 1253-1262 (2006)
27. Nielsen, J.: Diez heurísticas de usabilidad. (2007),
http://www.useit.com/papers/heuristic/heuristic_list.html
28. Walpole, R.E., Myers, R.H.: Probability and Statistics for Engineers and Scientists.
Macmillan Publishing Co., Inc, Basingstoke (1978)
