Integracion_de_la_IPO_y_la_ingenieria_del_software

Vista previa del material en texto

Integración de la IPO y la Ingeniería del Software: MPIu+a 
Granollers, Toni 
Dept. Informàtica i Enginyeria 
Industrial 
Universidad de Lleida 
tonig@diei.UdL.es 
 
 
Lorés, Vidal 
Dept. Informàtica i 
Enginyeria Industrial 
Universidad de Lleida 
Jesús@eps.UdL.es 
 
Sendin, Montse 
Dept. Informàtica i 
Enginyeria Industrial 
Universidad de Lleida 
msendin@eps.udl.es 
 
Perdrix, Ferran 
Dept. Informàtica i Enginyeria 
Industrial 
Universidad de Lleida 
fperdrix@diarisegre.com 
 
 
 
Resumen 
 
Actualmente, al desarrollar sistemas interactivos, 
ya nadie duda de la necesidad de los beneficios 
que comporta incorporar atributos fundamentales 
como son la usabilidad y la accesibilidad de los 
mismos. Y la disciplina de la Interacción Persona-
Ordenador (IPO) proporciona el marco idóneo 
para tener en cuenta dichos parámetros e 
incorporarlos a cualquier desarrollo. No obstante, 
los modelos de desarrollo que la industria 
actualmente utiliza para la producción de sus 
aplicaciones siguen siendo los propuestos por la 
Ingeniería del Software (IS). En este artículo 
presentamos una propuesta, MPIu+a, para el 
desarrollo de sistemas interactivos que integra los 
modelos y tareas específicos de la Usabilidad en 
el ciclo de vida de la IS, sin olvidar los aspectos 
relacionados con la accesibilidad para las personas 
con distintas discapacidades. 
1. Usabilidad de los Sistemas 
Interactivos: atributo de calidad 
En la elaboración de cualquier producto la calidad 
es uno de los aspectos más importantes para 
determinar si éste es mejor o peor que otro, y el 
desarrollo de productos interactivos no puede 
prescindir de este factor, sino más bien todo lo 
contrario. Uno de los parámetros de calidad más 
determinantes con relación a los sistemas 
interactivos es la Usabilidad de los mismos [3] 
hasta el punto que las más prestigiosas 
estandarizaciones (ISO 91, IEEE 98) vienen 
considerando este factor desde hace mucho 
tiempo. 
Muchas son las ventajas que la usabilidad 
puede proporcionar y por ello debería ser tratada 
cómo un factor de calidad estratégico y relevante 
[6]. 
La disciplina de la Interacción Persona-
Ordenador (IPO) estudia todos los factores 
relativos a la interacción entre los humanos y los 
sistemas interactivos con el objetivo de desarrollar 
o mejorar la seguridad, la utilidad, la eficiencia y 
la usabilidad de los productos interactivos basados 
en ordenadores. 
Diseñar un producto con una alta calificación 
respecto a su usabilidad no es fácil de conseguir, 
por lo que ésta debe ser considerada en todas las 
fases del desarrollo, desde el momento en que este 
comienza hasta el momento en que el producto o 
servicio es puesto en disposición del público. 
Los usuarios deben tener la sensación –real– 
de que el sistema les ayudará a realizar sus tareas 
–y este debe hacerlo–; de otra forma serán reacios 
a su utilización [16]. 
2. Diseño Centrado en el Usuario (DCU) 
Los sistemas interactivos son utilizados por 
personas a las cuales denominamos genéricamente 
cómo usuarios, los cuales no suelen “contar” para 
los diseñadores y desarrolladores de los sistemas 
hasta el momento de la puesta en funcionamiento 
del mismo, por tanto se ven relegados a la fase 
final de un proyecto cuando ya poco puede 
hacerse en su beneficio. 
El DCU de sistemas interactivos conlleva 
realizar un diseño pensando en y para el usuario, 
convirtiéndole en el punto central del desarrollo. 
Se le implica hasta el punto de incluirle, si cabe, 
cómo un miembro más del equipo de diseño. Se 
trata de conseguir productos fáciles de usar, 
efectivos y eficientes. 
El estándar internacional ISO, en concreto la 
ISO 13407, describe como un proceso de Diseño 
Centrado en el Usuario puede ser usado para 
conseguir sistemas usables. Este estándar 
proporciona un marco de trabajo para aplicar las 
técnicas en el diseño y la evaluación del DCU. La 
 
 
ISO 13407 especifica los tipos de actividades que 
deben realizarse durante el desarrollo de un 
sistema interactivo, no obstante no pide técnicas o 
métodos particulares, tan solo las recomienda. 
 
Figura 1. Interdependencia de las actividades del DCU 
(ISO 13407, pág. 6). 
Aún así los actuales sistemas interactivos se 
continúan desarrollando siguiendo los métodos 
propuestos por la Ingeniería del Software. 
3. Ingeniería del Software 
El término de Ingeniería del Software (IS) ha sido 
definido por varios autores. Veamos, por poner 
una de ellas, la que oficialmente expone el 
organismo IEEE [12]: 
Ingeniería de Software: (1) la aplicación de un 
enfoque sistemático, disciplinado y cuantificable 
hacia el desarrollo, operación y mantenimiento del 
software; es decir, la aplicación de la ingeniería al 
software. (2) El estudio de enfoques como en (1). 
Desde hace muchos años los ingenieros 
dedicados a la producción de software vieron la 
necesidad de disponer de modelos de proceso 
(entendiendo proceso cómo un conjunto 
organizado de actividades que transforman 
entradas en salidas, las descripciones del cual 
juntan o encapsulan conocimiento que podrá 
reutilizarse) para aplicarlos al desarrollo de “su 
producto” tal y cómo lo realizan otras áreas de la 
ingeniería. Cómo resultado de estas iniciativas han 
surgido varios modelos de proceso los cuales 
están perfectamente documentados en amplio 
abanico de libros y documentos. Algunos autores, 
incluso, han dedicado gran parte de su trabajo a 
recopilar y actualizar toda la información 
existente al respecto y publicando varias versiones 
de libros de IS considerados unos “clásicos” hoy 
en día; cómo los conocidos R.S.Pressman [17], I. 
Sommerville [19]. 
Modelos de proceso, tales como el “modelo en 
cascada”, “el modelo en V” [21] o el “modelo en 
espiral” [5] han sido propuestos y puestos en 
practica con mayor o menor éxito. 
4. Ingeniería de la Usabilidad 
El término de Ingeniería de la Usabilidad (IU) fue 
acuñado por primera vez por profesionales de 
usabilidad de Digital Equipment Corporation [10]. 
Usaron este término para referirse a los conceptos 
y técnicas para planificar, conseguir y verificar 
objetivos de la usabilidad de sistema. La idea 
principal es que los objetivos “medibles” de 
usabilidad deben ser definidos pronto en el 
desarrollo del software y después evaluarlos 
repetidamente durante el desarrollo para asegurar 
que se han conseguido [2][9]. 
Igual que en el caso de la IS varios autores 
han propuesto Modelos de Proceso (MP) válidos 
para la IU que permitan a los desarrolladores 
implementar sus aplicaciones bajo los parámetros 
de la usabilidad. Algunas de estas propuestas 
están enfocadas al trabajo de la evaluación 
heurística [15], otras al diseño contextual [1], a los 
casos esenciales de uso [6], al desarrollo de 
escenarios [18], o más de propósito más general 
[14][8]. 
A pesar de lo expuesto, actualmente, la 
industria no suele utilizar estos modelos sino que 
continúa aplicando los de la IS, los cuales no 
tienen en consideración la usabilidad. En el mejor 
de los casos una vez el producto está casi 
desarrollado se realizan tests enfocados a medir el 
grado de usabilidad del mismo. Creemos que esto 
es debido a que: 
• Los modelos de IU propuestos distan 
demasiado de los modelos de la IS, con lo cual 
el desarrollador lo ve cómo un cambio radical 
en su metodología de trabajo y continua con lo 
“de toda la vida”. 
• Los modelos de usabilidad propuestos hasta 
ahora son complejos [14][8], principalmente 
para aquellos integrantes de los equipos de 
diseño que no son profesionales de la 
informática. 
• Los ejecutivos no creen que la usabilidad está 
económicamente justificada [4]. Ven un 
 
 
aumento del proceso de desarrollo sin 
repercusión en las ventas. 
• Los responsables de marketing venden la 
imagen cómo base de una facilidad de uso que 
normalmente proviene de una simple 
apreciación subjetiva. 
• Jefes de proyecto, diseñadores y 
desarrolladores ven la disciplina IPO como 
una mera asignatura académica 
 
Hasta el presentela IPO ha sido mas bien 
cómo la cereza sobre el pastel [7]; viéndose cómo 
algo para hacer este pastel mas bonito para que 
proporcione un producto mas competitivo y 
comercial –estrategia de marketing–. La 
experiencia muestra que añadir la IPO como una 
“vestimenta para la ventana” ni es económico ni 
asegura la mejor solución desde una perspectiva 
de la usabilidad [13]. Por ello ahora es el 
momento pasar a hacer “el pastel de cerezas” –en 
lugar del pastel con la cereza cómo guinda–, y 
tenemos la necesidad de encontrar la manera de 
hacerlo utilizando las aproximaciones –cada vez 
mejores– de la Ingeniería de la Usabilidad con un 
enfoque Centrado en el Usuario. Si lo 
conseguimos tendremos el pastel deseado, con las 
cerezas distribuidas por todo el pastel de manera 
uniforme. 
Terry Winograd apunta acertadamente que el 
diseño de un buen software interactivo no es, ni 
ciencia, ni arte; no es aún una materia rutinaria de 
ingeniería [20]. Necesitamos, por tanto, casar la 
IS con la IPO [7]. 
Esta reflexión nos ha llevado a pensar que lo 
que realmente necesitamos es un Modelo de 
Proceso (MP) que resuelva los aspectos 
tecnológicos necesarios para que este panorama 
empiece a cambiar. Dicho MP debe, además, estar 
capacitado para su correcta aplicación en el más 
amplio abanico de casos posibles, abarcando 
desde aplicaciones simples hasta grandes 
proyectos realizados con las más modernas 
tecnologías y variedad de dispositivos posibles. 
Ha de tener un enfoque genérico a la vez que debe 
ser suficientemente conciso y robusto para que el 
desarrollador pueda implementarla sin 
vacilaciones. 
5. MPIu+a para la integración de la IS y 
la IU 
La Ingeniería del Software, cómo hemos visto, es 
una aproximación al desarrollo del software que 
engloba la definición de requisitos de la 
aplicación, la definición de objetivos y el 
diseño/desarrollo/pruebas. La IU utiliza los 
componentes generales de la IS proporcionando 
un proceso para el diseño y desarrollo de sistemas 
interactivos que sean usables. 
El Modelo de Proceso que proponemos [11] 
añade al modelo de la IS, una serie de actividades 
bien organizadas que a grandes rasgos las 
podemos clasificar como: 
• actividades estructuradas de los análisis de los 
requisitos donde la usabilidad cobra una 
importancia vital desde el primer momento 
• actividades de soporte a una aproximación 
estructurada del diseño de la Interfaz de 
Usuario 
• actividades de evaluación de los objetivos de 
usabilidad mediante iteraciones –hacia dichos 
objetivos– en el diseño 
5.1. Esquema de MPIu+a 
Algunos autores, como por ejemplo D. 
MAYHEW en [14], afirman que no existe ningún 
recetario que aporte principios generales de diseño 
de aplicaciones y guías de estilo seguras que 
permitan llegar a la solución ideal con sólo seguir 
una de sus recetas, a la vez que no puede llegarse 
a tal solución sin la ayuda de tales guías. 
Como hemos visto, entre las características 
principales de la usabilidad cabe destacar la 
claridad de la información y la consistencia, 
características que desde nuestra óptica también 
son aplicables a la accesibilidad del sistema. 
Otro aspecto que consideramos importante es 
que un método disponga de un esquema para que 
el usuario del modelo (componente del equipo de 
desarrollo) ubique en todo momento la fase del 
desarrollo en la que se encuentra y las 
posibilidades u opciones disponibles a partir de la 
ella para continuar su desarrollo. 
5.2. Caracteristicas 
El esquema de la figura anterior nos muestra las 
diferentes fases en las que se divide el modelo de 
proceso de la Ingeniería de la Usabilidad y la 
Accesibilidad y cómo se relacionan cada una de 
 
 
ellas. 
 
Figura 2. Esquema del modelo MPIu+a 
 
Las principales características del esquema, que 
son en definitiva las principales características del 
modelo de proceso, son: 
1. Organización conceptual. El esquema está 
organizado en base a una serie de módulos o 
etapas que determinan la fase de desarrollo en 
la que nos encontramos y ubica en un nodo 
concreto la actividad del conocimiento existente 
en IPO. Esto, en definitiva, no hace más que 
“poner cada cosa en su sitio”, dotando de las 
pautas a seguir durante el diseño de un sistema 
interactivo 
2. Tres pilares básicos. Como ya se ha 
mencionado con anterioridad, una de las metas 
más importantes de este modelo de proceso es 
conseguir “casar” el modelo de desarrollo de 
sistemas interactivos de la Ingeniería del 
Software con los principios básicos de la 
Ingeniería de la Usabilidad y los de la 
accesibilidad proporcionando una metodología 
que sea capaz de guiar a los equipos de 
desarrollo durante el proceso de 
implementación de un determinado sistema 
interactivo. 
 En la Ingeniería de la Usabilidad y en la IPO, 
en general hay dos conceptos muy importantes 
que deben realizarse de manera sistemática 
desde el inicio del desarrollo y no pueden cesar 
hasta la finalización del sistema: El prototipado 
y la evaluación 
 El esquema refleja muy claramente, con una 
codificación en colores, estos tres conceptos a 
modo de tres pilares básicos. 
 • La Ingeniería del Software, en el formato 
“clásico” de ciclo de vida en cascada iterativo o 
evolutivo (columna de la izquierda : 
Análisis/Diseño/Implementación/Instalación). 
 • El prototipado (columna central), como 
metodología que engloba técnicas que 
permitirán la posterior fase de evaluación. 
 • La evaluación (columna de la derecha) que 
engloba y categoriza a los métodos de 
evaluación existentes. 
3. El Usuario. En los modelos de desarrollo 
actuales los diseñadores y/o los programadores 
deciden por los usuarios, escogiendo las 
metáforas, organizando la información y los 
enlaces, eligiendo las opciones de los menús, 
etc. Dichas personas incluso, etiquetan sus 
aplicaciones como amigables al usuario o “user 
friendly”, a pesar de que ningún usuario real 
haya dado su aprobación a tal característica. 
 Si alguien tiene la potestad de calificar algo 
como user friendly éste es únicamente el 
supuesto user o usuario, que es la persona que 
interacciona con el sistema. 
 Un proceso de DCU debe dejar claro de que 
es así sólo con mirar el esquema la primera vez. 
Esto es lo que queda reflejado al disponer a éste 
en la parte central y por encima del resto de 
etapas todo el modelo de proceso. 
 Otro aspecto determinante en este modelo de 
proceso es que se da mucha importancia no sólo 
a los usuarios, sino también a los implicados en 
cuanto a que son personas que sin ser usuarios 
directos del sistema su actividad se ve afectada 
por el mismo. 
 Queda claro, pues, que el usuario está en el 
centro del desarrollo y en las facetas en las que 
interviene. 
4. Un método iterativo. Establecer procesos 
repetitivos es un aspecto natural que se da en 
cualquier otro ámbito de ingeniería, sea de la 
disciplina que sea. 
 Por poner un ejemplo de otra disciplina, en el 
mundo de la edificación existe incluso antes de 
empezar con la excavación del terreno una serie 
de reuniones (iteraciones) arquitecto-cliente 
(desarrollador-usuario) para conseguir que el 
diseño del futuro edificio se adapte a las 
necesidades de sus inquilinos. 
 
 
 Dicho proceso de repetición aplicado a la 
Ingeniería del Software también existe, aunque 
suele producirse en la fase final del proceso. 
 Volvamos al ejemplo anterior. ¿Qué pasaría si 
las reuniones entre el cliente y el arquitecto se 
realizasen una vez que la estructura del edificio 
ya estuviese levantada?. ¿Podría, por ejemplo, 
cambiar la posición o el tamaño de una 
ventana? o incluso ¿podría abrirse una nueva 
ventana en una pared maestra?.... Y si ello fuese 
técnicamente posible ¿cuál sería su coste?. 
 El esquema propuesto dispone de una serie de 
flechas cuyo objetivo no es otro que visualizar 
que desde todas las fases se promueve la 
participación activa de los usuarios, tanto en el 
análisis de requisitos como en el diseño y en la 
realización de prototipos y/o su posteriorevaluación. 
 Pueden observarse dos tipos de flechas, unas 
delgadas que se corresponden con el modelo de 
la IS, y otras más gruesas que convierten la IS 
en un verdadero modelo centrado en el usuario. 
Éstas últimas indican, entre otras cosas, donde 
interviene el usuario. 
5. Sencillez. Establecer procesos repetitivos es un 
aspecto natural que se da en cualquier otro 
ámbito de ingeniería, sea de la disciplina que 
sea. 
 Mayoritariamente los desarrolladores de 
sistemas interactivos que pretendemos que la 
usabilidad sea un factor determinante de los 
mismos estamos de acuerdo en que sus 
interfaces, sin perder su capacidad 
comunicativa y funcional, tienen que ser cuanto 
más sencillas y simples mejor. 
 Y si estamos de acuerdo con la premisa 
anterior estaremos igualmente de acuerdo con la 
idea de que la metodología que les permita 
llevar a cabo su trabajo de manera más eficiente 
sea también muy sencilla y simple. 
 El esquema aquí presentado nace con esta idea 
como trasfondo para todo el equipo de 
desarrollo: Es escueto, con pocos nodos y 
ramificaciones y sin caminos condicionales que 
dificultan su comprensión. 
 Las diferentes representaciones del sistema 
(diseño…) deben ser comprensibles, tanto por 
todos los componentes de los equipos 
(multidisciplinares) de desarrollo como por los 
usuarios y cualquier implicado que esté 
involucrado en el sistema, que sólo será posible 
construyendo dichas representaciones lo más 
simples posibles. 
6. Adaptado al modelo mental de los equipos 
multidisciplinares. El constante contacto con 
personas procedentes de áreas de conocimiento 
diversas ha servido para constatar la tan 
referenciada necesidad y a la vez la valiosa 
aportación que supone trabajar con estos 
equipos multidisciplinares. 
 Entre otros aspectos, experimentalmente 
constatamos que los modelos mentales de las 
diferentes personas distan mucho entre ellos, 
hecho que supone que surgen más dificultades 
de las previstas si los mecanismos de 
comunicación no son eficientes y las 
herramientas formales de modelado no son 
suficientemente simples. 
 Respecto a éstos, se ha constatado que utilizar 
métodos descriptivos en lenguaje natural junto 
con herramientas de uso habitual (aspectos 
comprensibles por todos los miembros del 
equipo) facilita el proceso comunicativo entre 
las personas que intervienen en el desarrollo. 
 Disponer, por otra parte, de un equipo de 
desarrollo formado por gente tan diversa no 
significa que todos ellos estén presentes en 
todas las fases del proyecto. Ni siquiera es 
preciso que todos tengan una visión completa 
de la evolución del desarrollo, lo que sí que es 
necesario es que cada uno tenga la visión 
necesaria y precisa del sistema desde su punto 
de vista y concerniente a su participación 
durante el proceso de desarrollo. 
 La siguiente figura refleja, de forma 
esquematizada, en un cuadro bidimensional que 
ubica gráficamente la relación disciplina-fase 
MPIu+a, dicha participación. 
 
 
Figura 3. Relación entre las diferentes disciplinas de un 
equipo multidisciplinar y su “particular” 
visión del MPIu+a 
 
 
Finalmente, no podemos olvidar que tanto los 
usuarios como los implicados en el sistema 
forman parte de este conglomerado 
pluridisciplinar y consecuentemente el modelo 
es también comprensible para ellos 
7. Flexibilidad. Debe destacarse también que el 
modelo no tiene ni un sentido lineal ni 
restrictivo, sino que fomenta la libre aplicación 
del mismo: Será el equipo de desarrollo 
(representados normalmente por el responsable 
del proyecto en desarrollos de envergadura 
considerable o el diseñador o programador más 
experimentado en desarrollos menores) junto 
con los propios requisitos del sistema, las 
particularidades de los usuarios y los resultados 
de las diferentes evaluaciones quien marcará 
cuantas iteraciones deben realizarse, como 
deben hacerse y el flujo de las acciones a 
realizar en cada iteración. 
5.3. Metodología de validación del MPIu+a 
Hemos visto que según el punto de vista de la 
Ingeniería del Software los procesos descritos por 
las técnicas dependientes o descendientes de la 
disciplina IPO echan en falta un mayor grado de 
formalidad, mientras que por otra parte la propia 
IS desarrolla sistemas centrándose en los aspectos 
internos del sistema, en la lógica del proceso y en 
las estructuras de los datos olvidando los aspectos 
relacionados con los usuarios finales. A pesar de 
ello, el objetivo es común a ambas visiones, 
pretenden desarrollar sistemas interactivos de 
calidad (también hemos visto que dicha calidad 
necesita la aportación de ambas visiones [ISO01]). 
Uno de los objetivos principales de este 
trabajo ha sido no tan sólo proponer, sino también 
validar una propuesta integradora de ambas 
visiones incorporando además aquellos aspectos 
de otras disciplinas relacionadas que 
habitualmente son olvidadas. 
El método de validación escogido para la 
propuesta previamente presentada es la utilización 
de un gran número de proyectos reales 
desarrollados siguiendo el modelo de proceso 
propuesto. El verdadero laboratorio de ensayo de 
la metodología es la diversidad de proyectos 
reales y proyectos docentes los más destacados de 
los cuales se han mostrado al principio del 
documento y a los que se ha hecho constante 
referencia en los ejemplos de aplicación de las 
técnicas descritas en el documento. 
Este método de validación es el más arduo de 
realizar pero tiene la compensación de ser 
mediante el cual se obtienen los resultados más 
contrastados y determinantes. Arduo en el sentido 
de que es necesario entrar en el mercado industrial 
en busca de proyectos, en que es necesario 
“gastar” todo el tiempo de desarrollo, sin dejar 
aspectos sin resolver, —incrementado, en parte, al 
tratarse de una combinación de las técnicas 
existentes con las que se pretende investigar su 
validez— y en el sentido de que deben cumplirse 
los plazos temporales y presupuestarios 
establecidos en el contrato con el cliente (aspectos 
habitualmente olvidados en entornos de 
investigación). 
Mirando la vertiente positiva, encontramos 
mayor calidad en los resultados obtenidos. Al 
tratarse, pues, de proyectos reales tanto los 
usuarios finales como los implicados y los 
componentes del equipo de desarrollo procedentes 
de otras disciplinas también son reales y la 
validación de la usabilidad y de la accesibilidad 
final de cada sistema tiene unos destinatarios 
perfectamente determinados que manifiestan 
abiertamente su grado de satisfacción –
insatisfacción– y de conformidad –
disconformidad– con el producto entregado. 
La metodología incorpora un apoyo de la 
calidad del modelo basada en la evaluación de 
cada proyecto en particular y un esquema para 
mejorar el modelo basado en las mejoras 
adquiridas como resultado de su aplicación. 
Uno de los aspectos destacados que se 
pretendían era poder demostrar que seguir una 
metodología de trabajo centrada en el usuario es 
válida y adaptable para todos los tipos de 
paradigmas de interacción existentes. Así pues, las 
aplicaciones sobre las cuales se ha probado la 
metodología están desarrolladas bajo paradigmas 
tan diversos como son la Realidad Aumentada, la 
Computación Ubicua o el entorno web dando 
como resultados una validación del método, así 
como una serie de mejoras a la idea inicial que ha 
permitido concretar el modelo de proceso tal y 
como se ha explicado en los apartados anteriores. 
 
 
 
 
5.4. Actividades de protección y de 
planificación 
Para ello, nos basamos en actividades de 
protección de la Ingeniería del Software para dar 
soporte metodológico al proceso de desarrollo con 
el propósito principal de obtener un producto de 
calidad demostrable [PRE00a]. La manera en la 
que el MPIu+a integra la Ingeniería del Software 
es extendiendo esta hacia la gestión de la calidad 
de la usabilidad y la accesibilidad usando: 
 
 
Figura 4. Actividades de protección de la IS que 
garantizan la calidad de los desarrollosrealizados siguiendo el MPIu+a. 
• La Gestión de la Configuración (GC) como el 
mecanismo de protección que permite 
gestionar el cambio durante toda la vida de 
servicio de un sistema interactivo. Será 
necesario identificar, organizar, controlar y 
documentar todas las modificaciones que se 
irán sucediendo. Esta GC empieza en el 
mismo instante que lo hace el desarrollo y 
sólo puede finalizarse cuando el producto es 
retirado del mercado [PRE00a]. 
• El Aseguramiento o la Garantía de la Calidad 
del Software (GCS) que sobre la base de 
diseñar planes específicos que consisten en la 
inspección, revisiones y evaluaciones 
realizadas, también, durante todo el ciclo de 
vida de la aplicación permitirá asegurar que 
cada parte del producto cumple perfectamente 
con la totalidad de los requisitos para la que 
fue pensada, diseñada e implementada. Ello 
permitirá asegurar la calidad efectiva del 
producto final. Las Revisiones Técnicas 
Formales (RFTs) es una vía de probada 
efectividad para llevar a término esta revisión 
y mejora constante de la calidad del proyecto. 
• La Gestión del Riesgo (GR) constituye otra 
actividad de protección básica. Sabemos que 
el riesgo hace referencia a la posibilidad de 
sufrir pérdidas, y cierto es que cualquier 
proyecto está sujeto a un cierto número de 
estas posibilidades, las cuales producen un 
impacto sobre el mismo. Este impacto puede 
darse en forma de disminución de la calidad 
final del producto, incremento de los costes de 
producción, retrasos en las entregas, o 
simplemente en fallos. La actividad de la GR 
es una práctica de la Ingeniería del Software 
que aporta procesos, métodos y herramientas 
suficientes para gestionar el mayor número 
posible de riesgos a los que un proyecto puede 
verse sometido y, sobre todo, decidir cómo 
actuar en caso de producirse en beneficio del 
proyecto [SEI02]. 
 
Este conjunto de actividades que “envuelven” 
el MPIu+a (ver figura 3) debe estar correctamente 
sincronizado con la planificación del proyecto, la 
cual debe estar permanentemente en constante 
revisión certificando la correcta ejecución del 
proceso global para que se cumpla. 
6. Conclusiones 
Después de situar el contexto del desarrollo de 
aplicaciones interactivas bajo los parámetros 
descritos en la disciplina Interacción Persona-
Ordenador, hemos expuesto nuestro punto de vista 
sobre las diferentes propuestas en cuanto a 
Modelos de Proceso de la Ingeniería de la 
Usabilidad, para la cual hemos propuesto un 
nuevo Modelo. 
Estamos desarrollando varias aplicaciones en 
diferentes paradigmas (web, sobremesa y 
ubicuos) las cuales utilizamos para probar la 
validez de la metodología presentada. Las 
evaluaciones finales de dichas aplicaciones nos 
han dado resultados muy satisfactorios en cuanto 
al grado de usabilidad de los mismos sin detectar 
incrementos considerables en el tiempo de 
desarrollo comparado con otras metodologías. 
Con este trabajo pretendemos proporcionar no 
solo una metodología útil y comprensible, sino 
que también pretendemos definir y resolver el 
Índice de Calidad de Usabilidad del software así 
cómo desarrollar una herramienta de soporte para 
los ingenieros que desarrollen su trabajo bajo el 
Modelo de Proceso propuesto. 
 
 
Agradecimientos 
El trabajo presentado en este artículo forma parte 
de las actividades a realizar previstas para el 
primer año del proyecto de investigación 
SISTEMAS ADAPTATIVOS Y 
COLABORATIVOS CON SOPORTE WEB 
(ADACO) de referencia TIN2004-08000-C03-03 
en el marco del Plan Nacional de Investigación 
Científica, Desarrollo e Innovación Tecnológica 
2004-2007. 
Referencias 
[1] Beyer, H.; Holtzblatt K.: Contextual Design: 
Definig Customer-Centred Systems : Morgan 
Kauffmann (1998) 
[2] Bennet J.: Managing to meet usability 
requirements. In Visual Display Terminals: 
Usability Issues and Health Concerns : 
Prentice-Hall (1984). 
[3] Bevan N. (Research Manager at Serco 
Usability Services); Quality in Use: Meeting 
User Needs for Quality: Journal of System 
and Software (1999) 
[4] Bias R.G.; Mayhew D.J.: Cost-justifying 
usability: IEEE Software. (1991) 
[5] Boehm, B.: A Spiral Modelo for Software 
Development and Enhancement: Computer, 
vol.21, nº5 (may 1998) p.61-72 
[6] Constantine, L.L.; Loockwood L.A.D.: 
Software for Use: A Practical guide to the 
Models and Methods of Usage-Centered 
Design : Addison-Wesley (1999) 
[7] Faulkner X.; Culwin F.: Enter the Usability 
Engineer: Integrating HCI and Software 
Engineering : ACM 2000. 
[8] Gerrit, C. van der Veer: Human computer 
Interaction: learning, individual differences, 
and design recommendations : Doctoral 
Thesis : Vrije Universiteit, Amsterdam. 
(1990) 
[9] Gilb T.: The Impact Analysis Table applied to 
human factors design: Proceedings of the 1st 
IFIP Conference on Human-Computer 
Interaction-INTERACT ’84 (Amsterdam) 
(1984) 
[10] Good M.; Spine T.M.; Whiteside J.; George 
P.: User-derived impact analysis as a tool for 
usability engineering: Proceedings of Human 
Factors in Computing Systems: CHI’86. New 
York: ACM (1986) 
[11] Granollers, T. (2004). MPIu+a. Una 
metodología que integra la Ingeniería del 
Software, la Interacción Persona-Ordenador y 
la Accesibilidad en el contexto de equipos de 
desarrollo multidisciplinares. Tesi Doctoral. 
Universitat de Lleida. 
[12] IEEE P610 Computer Dictionary Project, 
http://grouper.ieee.org/groups/610/p610home.
html 
[13] Jordan P.: An Introduction to Usability : 
Taylor and Francis, ISBN: 0748407944 
(1998). 
[14] Mayhew D.J.: The Usability Engineering 
Lifecycle: A practitioner’s Handbook for User 
Interface Design : Morgan Kaufman (1999) 
[15] Nielsen, J.: Heuristic evaluation. In Nielsen, 
J., and Mack, R.L. (Eds.), Usability Inspection 
Methods. John Wiley & Sons, New York, NY. 
(1994). 
[16] Nielsen J.: Usability Engineering : Academic 
Press. ISBN 0-12-518406-9 (1994) 
[17] Pressman R.: Software Engineering: A 
Practitioner’s Approach: 5th Edition. Mc 
Graw-Hill (2001) 
[18] Rosson, M.B.; Carroll, J.M.: Usability 
Engineering: scenario-based developement of 
HCI: Morgan Kaufmann (2002) 
[19] Sommerville I.: Software Engineering: 6th 
Edition (2000) 
[20] Winograd T. Foreword of Rosson & Carroll 
“Usability Engineering” book (2002) 
[21] Davis, A. : “Software Requirements: 
Analysis and Specification” : Prentice-Hall 
(1990).