FACULTAD 8
PR P RO OP PU UE ES S TA T A Y Y A AN N ÁL Á LI IS S IS I S D DE E L LA A A AR RQ QU UI IT TE EC CT TU UR RA A DE D E I IN N FO F OR RM M A A CI C IÓ ÓN N E EN N E EL L P PR RO OY YE EC CT TO O C CI IC CP PC C
Trabajo de Diploma para optar por el Título de Ingeniero en Ciencias Informáticas
A A ut u to o ra r a: : Mailin Carballosa Infante T Tu ut t or o re e s: s : Lic. Deymis Tamayo Rueda
Ing. Sasha Valdés Jiménez
Ciudad de La Habana, 2008
“Año 50 de la Revolución”
DE D EC CL LA AR RA A CI C IÓ ÓN N D DE E A AU UT TO OR RÍ ÍA A
Declaro que soy la única autora del presente Trabajo de Diploma y reconozco a la Facultad 8 de la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de _________ del año 2008.
______________
Firma de la Autora Mailin Carballosa Infante
______________ ______________
Firma de la Tutora Firma del Tutor
Deymis Tamayo Rueda Sasha Valdés Jiménez
DA D AT TO OS S D DE E C CO ON NT TA AC CT T O O
Deymis Tamayo Rueda. Licenciada en Bibliotecología y Ciencias de la Información, graduada en la Facultad de Comunicación de la Universidad de La Habana. 2 años de experiencia. Especialista en Arquitectura de Información. Brinda servicios al Departamento de Ingeniería de Software y Práctica Profesional y pertenece al Departamento de Humanidades de la Facultad 8 de la referida institución.
Residencia UCI: Edificio 41, apto 203. Teléfono: 835-8836. Correo electrónico: [email protected]
Sasha Valdés Jiménez. Ingeniero en Ciencias Informáticas, graduado de la Universidad de las Ciencias Informáticas. 2 años de experiencia. Especialista en Análisis de Sistemas. Pertenece al Departamento de Ingeniería de Software y Práctica Profesional de la Facultad 8 de la referida institución. Residencia UCI: Edificio 26, apto 108. Teléfono: 835-8785. Correo electrónico:
"Hay tanto que decir, que ha de decirse en el menor número de palabras posible:
eso sí, que cada palabra lleve ala y color".
José Martí
AG A GR RA AD DE EC CI IM MI IE EN NT TO OS S
…A La Revolución Cubana y al Comandante Fidel Castro por hacer realidad el sueño de convertirme en una profesional…A La Universidad de las Ciencias Informáticas (UCI) por los momentos vividos…A mis padres, por darme siempre lo mejor de sí, apoyarme en todo momento y por ser mi guía en la vida…A mi novio, por su comprensión y amor que me hace seguir adelante todos los días de mi vida…A mis abuelos, Cachita y Oscar, por ser únicos…A mi tutora, Deymis, por ser inigualable, por sus incontables consejos, tiempo brindado, sabiduría y ayuda a lo largo del desarrollo del trabajo…A mi tutor, Sasha, por los consejos y sugerencias en todo momento, por nunca estar conforme con nada y mostrarme que puede ser mejor… A toda mi familia en general, por su cariño, fe en que puedo hacer todo lo que me proponga…A mi hermano, primos y generaciones futuras, primera universitaria sí, pero no quiero ser la única…A Yadenis, porque esta tesis también es suya …A todos mis amigos y compañeros, gracias por estar siempre…A Lazarita, por ser mi madre en la UCI y brindarme su cariño y a Frank también, por sus consejos…A los profesores del proyecto y de la facultad por sus recomendaciones, sugerencias en todo momento…A todos los que de una manera u otra, me han extendido su mano y han puesto en mí un granito de tesón, dándome fuerzas para seguir luchando por este sueño que hoy se cumple.
A todos, les doy mis más sentidos agradecimientos.
A A m m is i s P Pa a dr d r e e s s , , p po or r s s e e r r l l o o s s m m e e j j o o re r es s de d el l m mu u nd n do o
RE R ES SU UM M EN E N
El inminente avance de las ciencias informáticas y la necesidad de desarrollo industrial y económico, han provocado el crecimiento de la industria cubana del software. La Universidad de las Ciencias Informáticas (UCI) promueve el desarrollo de la informática tanto para el ámbito nacional como internacional, mediante la realización de proyectos productivos que vinculan estudiantes, profesores y profesionales afines a la producción de software. Uno de estos proyectos es precisamente el plan de modernización del Sistema Integrado de Información Policial (SIIPOL), desarrollado para el Cuerpo de Investigaciones Científicas, Penales y Criminalísticas (CICPC), de la República Bolivariana de Venezuela, con el objetivo de solucionar problemas generados por un control deficiente de la información en dicha organización.
La inserción de la disciplina Arquitectura de Información (AI) dentro del proceso de desarrollo de software es de total premura para lograr un producto de alta calidad que cumpla con principios de usabilidad y accesibilidad para el usuario final de la aplicación.
El presente trabajo constituye una propuesta de Arquitectura de Información aplicada al Proyecto CICPC, encaminada a la obtención de un software funcional de alta calidad que genere en el usuario un gran impacto. Además se establecen aportes teóricos que insertan la Arquitectura de Información dentro de la Metodología de Proceso Unificado de Software (RUP).
Palabras Clave
Arquitectura de Información, Calidad de Software, Usabilidad, Prototipado de Interfaz de Usuario, Proceso Unificado de Software
TA T AB BL LA A D DE E C CO ON NT TE EN NI ID D O O
INTRODUCCIÓN ...1
CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA ...5
1.1 Introducción ...5
1.2 Arquitectura de Información ...5
1.2.1 Antecedentes ...5
1.2.2 Algunas Definiciones ...5
1.2.3 Importancia de la Arquitectura de Información ...7
1.2.4 Arquitectura de Información como proceso gerencial...8
1.2.5 Arquitectura de Información y su relación con RUP ...8
1.3 El Prototipo de Interfaz...13
1.3.1 Tipo de Prototipos ...14
1.3.2 Niveles de Prototipado...15
1.3.3 Fases en el Proceso de Prototipado ...16
1.3.4 Objetivos del Prototipo...17
1.3.5 Técnicas para la Aplicación de Prototipos ...18
1.3.6 Estrategias de Diseño de Prototipos de Interfaces de Usuario ...20
1.3.7 Papel del Prototipo...21
1.3.8 Usabilidad ...22
1.4 Aplicaciones y Herramientas para Diseñar Prototipos ...22
1.4.1 Normas que Respaldan el uso de Prototipos...23
1.4.2 Herramientas para realizar Prototipos...23
1.5 Calidad de Software ...24
1.5.1 Listas de Chequeo como instrumento de Validación ...25
1.6 Técnicas de Recopilación de Información ...25
1.7 Rol del Arquitecto de Información...26
1.8 Conclusiones ...26
CAPÍTULO 2. PROPUESTA DE ARQUITECTURA DE INFORMACIÓN ...28
2.1 Introducción ...28
2.2 Arquitectura de Información y RUP ...28
2.3 Levantamiento de Información...30
2.3.1 Actividades en el Levantamiento de Información...32
2.3.2 Artefactos generados en el Levantamiento de Información ...37
2.4 Desarrollo de Pautas de Arquitectura de Información ...38
2.4.1 Definición de Pautas de Arquitectura de Información ...39
2.4.2 Definición de Componentes visuales ...40
2.4.3 Artefactos Generados en el Desarrollo de Pautas de Arquitectura de Información ...41
2.5 Diseño de Prototipos de Interfaces de Usuario ...45
2.5.1 Artefactos Generados ...47
2.6 Evaluación de la Arquitectura de Información ...48
2.7 Conclusiones ...51
CAPÍTULO 3. ANÁLISIS DE RESULTADOS Y VALIDACIÓN DE LA PROPUESTA...53
3.1 Introducción ...53
3.2 Aplicación de encuestas al Equipo de Desarrollo ...53
3.2.1 Análisis de Resultados de las encuestas realizadas antes de la aplicación de la propuesta de Arquitectura de Información ...54
3.2.2 Análisis de Resultados de las encuestas realizadas después de la aplicación de la propuesta de Arquitectura de Información ...54
3.2.3 Tiempo de Desarrollo...55
3.3 Guía para la Validación por Expertos ...56
3.4 Conclusiones ...62
CONCLUSIONES ...63
RECOMENDACIONES...64
REFERENCIAS BIBLIOGRÁFICAS ...65
BIBLIOGRAFÍA ...67
GLOSARIO DE TÉRMINOS ...68
ANEXOS ...70
Anexo I: Documento de Pautas de Arquitectura de Información del Proyecto CICPC ...70
Anexo II: Librería de Componentes para el Proyecto CICPC...94
Anexo III: Resultados de la encuesta inicial...95
Anexo IV: Resultados de la encuesta después de aplicada la propuesta...96
Anexo V: Modelo para la recogida de información referente a la calificación de los criterios para la evaluación por expertos. Primera vuelta ...97
Anexo VI: Modelo para la recogida de información referente a la calificación de los criterios para la evaluación por expertos. Segunda vuelta ...98
ÍN Í ND DI IC CE E D DE E F FI IG GU UR RA AS S
Figura 1. Proceso Unificado ...9
Figura 2. Actividades de la Arquitectura de Información ubicadas en RUP. ...29
Figura 3. Diagrama de Procesos del Flujo de Trabajo Modelamiento del Negocio incluyendo la Arquitectura de Información...31
Figura 4. Detalles del Proceso Levantamiento de Información. ...32
Figura 5. Diagrama de Procesos del Flujo de Trabajo Requerimientos...38
Figura 6. Detalles del Subproceso Desarrollo de Pautas de Arquitectura de Información. ...39
Figura 7. Diagrama de Procesos del Flujo de Trabajo Análisis y Diseño. ...45
Figura 8. Detalles de Proceso Analizar el Comportamiento vinculado a la Arquitectura de Información 46 Figura 9. Diagrama de Proceso del Flujo de Trabajo de Prueba ...49
Figura 10 . Detalles del Subproceso Probar y Evaluar. ...50
ÍN Í ND DI IC CE E D DE E T TA AB BL LA AS S
Tabla 1. Planificación de actividades de la Arquitectura de Información en el proyecto. ...56Tabla 2. Valor otorgado por los expertos a los criterios...58
Tabla 3. Resultado de las pruebas de Kendall y X2 deFriedman. ...59
Tabla 4. Valor otorgado por los expertos a los criterios en la segunda vuelta. ...60
Tabla 5. Resultado de las pruebas de Kendall y X2 deFriedman en la segunda vuelta. ...61
Tabla 6. Cálculo del Peso por la Estadística Descriptiva del SPSS. ...61
1
I I N N T T R R O O D D U U C C C C I I Ó Ó N N
La demanda de los productos de software y los servicios de información tecnológica tienen una de las tasas de crecimiento mundiales más alta en la actualidad. Las Tecnologías de la Información y Comunicación (TICs) juegan un papel relevante en la economía mundial. Su capacidad de atracción de inversión y generación de valor, se ve reflejada en la detonación de nuevas capacidades productivas, así como en la generación de empleos bien remunerados en diferentes economías del mundo. La industria del software y servicios informáticos (SSI) ha sido una de las más dinámicas a escala global en los últimos años. Esto no es sorprendente, considerando que el software juega un papel clave dentro del conjunto de avances tecnológicos.
Los países desarrollados son, sin lugar a dudas, los mayores productores y consumidores de software en el mundo, destacándose en un 50% los EEUU. Sin embargo, existen algunos países en desarrollo (PED) que han alcanzado una inclusión significativa en los mercados internacionales, siendo los casos más notorios el de la India, Irlanda e Israel, países de “ingreso tardío” que han alcanzado un gran éxito en esta industria.
Por la Industria del Software aportar significativos avances en diferentes facetas, como en la Economía, la Socialización del Conocimiento, en las Herramientas para manejar la información, por citar algunos ejemplos, merece que los productos que ella genera salgan con la calidad requerida.
Hoy en día, las compañías de todo el mundo industrializado, reconocen que la calidad del producto se traduce en ahorro de costos y en una mejora general. La Industria de Desarrollo de Software no es la excepción, por lo que en los últimos años se han realizado intensos trabajos para aplicar los conceptos de Calidad en el ámbito del software. La Calidad del Software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. Es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, portabilidad, usabilidad, seguridad e integridad. Para lograr que un software cumpla con dichas propiedades se hace necesaria la utilización de metodologías o procedimientos estándares para todas las fases de desarrollo del mismo.
La información y el acceso a ella, como primera necesidad en un mundo conectado a través de las TICs y los distintos niveles de información y de comprensión de la misma por el hombre, son problemas que surgen cuando se habla de calidad en el mundo de la Industria de Software. Este es, sin lugar a dudas, el nicho de la Arquitectura de Información (AI), disciplina encargada de la fundamentación, análisis, planificación y estudio de la disposición de los datos contenidos en los sistemas de información interactivos. Esta posibilita organizar conjuntos de información, permitiendo
2 que cualquier persona los entienda y los integre a su propio conocimiento, de manera simple. Su surgimiento está marcado por la necesidad de estandarizar la forma de presentarle la información al usuario para diferentes entornos y que esta información sea a su vez asequible, y fácil en su uso y entendimiento.
En sus inicios, la Arquitectura de Información se empleó solamente en el entorno Web, para desarrollar sitios y portales, sin embargo, ¿por qué no aplicarse a cualquier software? Esta interrogante fue la base para que se empezara a incorporar la Arquitectura de Información en la elaboración de cualquier producto informático.
El Gobierno Cubano se dio a la tarea de desarrollar la Industria del Software, con la finalidad de desarrollar Sistemas para la informatización de la sociedad, y para lograr escalar en el Mercado del Software a nivel mundial, debido a las ventajas económicas que esto ofrece. La Universidad de las Ciencias Informáticas (UCI), surgida al calor de la Batalla de Ideas y precisamente para impulsar el desarrollo de la informática en nuestro país, forma a sus estudiantes bajo la premisa de combinar la docencia con la producción, preparándolos como futuros informáticos. Su producción está enfocada tanto al ámbito nacional como al internacional y tiene como Perfiles de Producción, creación de Portales y Sitios Web, productos Multimedia y en menor proporción Software de Gestión. Por ser la aplicación de la Arquitectura de Información a un software de gestión algo novedoso, no se poseía un documento oficial que plasmara una guía de realización de los procesos vinculados a esta rama del conocimiento; además no existía uniformidad de criterios entre los especialistas encargados de establecer las tareas de la Arquitectura de Información en los proyectos productivos, ya que estos trabajaban de forma aislada guiándose por criterios propios.
En el marco de la colaboración de los países de la Alternativa Bolivariana para las Américas (ALBA), se involucran Cuba y Venezuela en un proyecto de Modernización del Cuerpo de Investigaciones Científicas, Penales y Criminalísticas (CICPC) que abarca principalmente la creación de un software que gestione de manera más oportuna, ágil y eficaz sus procesos, para una mejor respuesta a la investigación y lucha contra el delito, en beneficio de la sociedad venezolana. Para dar cumplimiento a esta importante tarea asignada a la UCI fue creado el proyecto CICPC, con estudiantes pertenecientes a la Facultad 8. En los inicios del proyecto, el montaje de prototipo de interfaces de usuario no reflejaba los conocimientos básicos de Arquitectura de Información que era necesario para esta tarea. Existía una diferencia de criterios en cuanto a la forma de organizar y visualizar la información en las interfaces de usuario entre Analistas y Aseguradores de Calidad Interna del proyecto. Además, se desconocía cómo vincular la Arquitectura de Información al proceso de desarrollo del software. Todas
3 estas razones provocaban que el producto final de dichas interfaces no contara con la calidad necesaria.
A partir de lo antes expuesto, el problema científico es la ausencia de una estrategia para gestionar la Arquitectura de Información en el Software de Gestión del CICPC.
Por lo tanto el objeto de estudio está centrado en la Arquitectura de Información para Software de Gestión.
El campo de acción del presente trabajo está conformado por los procesos donde interviene la Arquitectura de Información en el Software de Gestión para el CICPC.
El presente trabajo surge por la necesidad de dar solución al problema planteado anteriormente, por tal razón se ha trazado como objetivo general crear una Guía para la Arquitectura de Información en el Software de Gestión para el CICPC.
Dentro de los objetivos específicos planteados en el trabajo se encuentran:
Establecer los elementos teóricos de la Arquitectura de Información para Sistemas de Gestión en ambiente Web.
Diseñar las Pautas de Arquitectura de Información para el Proyecto CICPC.
Analizar el comportamiento de la aplicación de las Pautas de Arquitectura de Información.
Para cumplir con los objetivos específicos, se trazaron las siguientes tareas:
Profundización en el estudio acerca de la Arquitectura de Información y Calidad de Software.
Estudio y análisis de los requerimientos del Sistema de Investigación e Información Policial (SIIPOL).
Estudio del plan de captura de requerimientos definido para el proyecto.
Realización de un estudio de las herramientas para la aplicación de la Arquitectura de Información en prototipos de interfaces de usuario.
Elaboración de una Biblioteca de Componentes.
Elaboración de las Pautas de Arquitectura de Información.
Definición de las actividades y artefactos a desarrollar en el producto y que es responsabilidad del arquitecto de información.
Aplicación de las Pautas de Arquitectura de Información al proyecto CICPC.
Evaluación del impacto de la solución en el proceso de Desarrollo.
Validación, por parte de expertos, de la propuesta de las Pautas de Arquitectura de Información para el CICPC.
Realizar encuestas a integrantes del CICPC para evaluar la aceptación de la propuesta.
4 Como idea a defender se expone que al diseñar y aplicar las Pautas de Arquitectura de Información al Proyecto CICPC, se logrará un software de alta calidad en cuanto a Organización de Información, Usabilidad y Accesibilidad para todos sus usuarios.
Los métodos empleados para nuestra investigación son los históricos-lógicos: analítico-sintético para la recopilación de información sobre el tema que se trata y sus antecedes, también se utiliza el método empírico, y más específicamente la observación. Para validar la propuesta que se presenta en este trabajo también se emplea la entrevista a expertos con una población de 7 expertos en Arquitectura de Información. Para la aceptación del resultado final se realizarán encuestas a los integrantes de CICPC con una muestra de 20 personas.
Las técnicas empleadas son las de Análisis documental, Encuesta y Entrevistas.
Estructura Capitular
Capítulo 1. Marco teórico–conceptual sobre Arquitectura de Información, el arquitecto de información como especialista que desempeña la arquitectura, y sobre principios de la Metodología de Proceso Unificado de Software.
Capítulo 2. Vinculación de la Arquitectura de Información como proceso que se inserta dentro de la Metodología de Proceso Unificado de Software, y desarrollo de las fases de la Arquitectura de Información durante todo el periodo de creación de software, con sus respectivos artefactos generados de estas etapas.
Capítulo 3. Análisis de resultados mediante aplicación de encuestas a usuarios internos del Proyecto CICPC y validación de la propuesta para medir su calidad y efectividad mediante entrevista y encuesta a expertos en Arquitectura de Información.
5
C C A A P P Í Í T T U U L L O O 1 1 . . F F U U N N D D A A M M E E N N T T A A C C I I Ó Ó N N T T E E Ó Ó R R I I C C A A
1.1 Introducción
La Sociedad de la Información y las Tecnologías de la Información y las Comunicaciones se han materializado y han alcanzado su desarrollo a partir de la especificación del protocolo de transferencia de hipertexto (HTTP), el cual revolucionó la búsqueda y recuperación de información en Bases de Datos en los años 80 y principios de los 90 hasta la actualidad. A partir de este momento surge la WWW “…elemento que ha popularizado finalmente a Internet, por la variedad y versatilidad de las páginas, aunque sólo se trate de uno de sus servicios” (Gómez Reyes, 2002)
1.2 Arquitectura de Información
1.2.1 Antecedentes
El término Arquitectura de Información fue usado por primera vez por el arquitecto de profesión Richard Wurman en la conferencia del Instituto Americano de Arquitectos que se celebró en 1976. En el año 1996, publica su libro "Information Architects" en el que aportaba definiciones de su concepto de Arquitectura de Información.
La Arquitectura de Información (AI) se ocupa de trasformar la información almacenada en información útil. Muchas veces las dificultades radican en que no siempre se puede recuperar toda la información existente sobre un tema determinado porque no se realiza un adecuado proceso de clasificación e indización y en ocasiones también se dificulta la recuperación de la información contenida en una página Web por una inadecuada organización de los contenidos.
Se puede aseverar que los problemas que han de estudiarse en un sistema de comunicación tienen que ver con la cantidad de información y la capacidad del canal de comunicación para la difusión y la recuperación de la misma. (Gómez Reyes, 2002)
1.2.2 Algunas Definiciones
Existen varias definiciones sobre Arquitectura de Información como la de Rosenfeld y Peter Morville en su libro "Information Architecture for the World Wide Web”, o como mejor se conoce "Libro del Oso Polar", los cuales plantean que la Arquitectura de Información se refiere al diseño, organización, etiquetado, navegación y sistemas de búsqueda que ayudan a los usuarios a encontrar y gestionar la información de manera efectiva. Plantean además que la Arquitectura de Información determina la
6 funcionalidad que el sitio va a tener, especifica cómo los usuarios van a encontrar la información al definir su organización, navegación, etiquetado y sistemas de búsqueda y representa cómo el sitio se va a acomodar al cambio y crecimiento en el tiempo, así como que organiza, rotula, sistematiza, titula y nombra los botones que realizan acciones en un sistema.
Otros autores como Steve Toub, de Arhus Associates, refiere que la Arquitectura de Información es el arte y la ciencia de estructurar y organizar el entorno informativo para ayudar a los usuarios eficientemente a satisfacer sus necesidades informativas.
James Garret, Jesse en “Elements of user Experience” la define como el Diseño estructural del espacio informacional para facilitar el acceso intuitivo a los contenidos”. (James Garret, 2002)
La Consultoría de Arquitectura de Información, en su Portal de Arquitectura de Información1 resume los conceptos anteriores, pues establece que la Arquitectura de Información es la disciplina que organiza la información, permitiendo que cualquier persona los entienda y los integre a su propio conocimiento, de manera simple. Se utiliza fundamentalmente en espacios virtuales donde se requiere que el propio usuario obtenga la Información. Es el estudio de la organización de la información con el objetivo de permitir al usuario encontrar su vía de navegación hacia el conocimiento y la comprensión de la información.
Para la autora del presente trabajo la Arquitectura de Información es la disciplina que se encarga del estudio, análisis, fundamentación y disposición de los contenidos en un sistema de información.
La Arquitectura de Información como disciplina no busca definir una metodología de diseño universal sino articular un conjunto de técnicas para ayudar al desarrollo y producción de los productos electrónicos, no trata sobre el establecimiento de un conjunto de pasos o guías predefinidas, sino del diseño inteligente que subyace detrás de una interfaz o espacio de información. Trata de maximizar las asociaciones que se producen entre interactividad, navegación y contenido con el objetivo de alcanzar una integración sistémica con el cerebro del usuario logrando un fenómeno de persuasión, conocimiento o información que se traspasa de un sistema de información a otro.
Para lograr una mejor asimilación de los contenidos por parte de los usuarios de forma eficiente y efectiva, la Arquitectura de Información se encarga en los estudios de audiencia y la definición del público objetivo de:
El diseño de la interacción.
El diseño de la navegación.
La planificación, desarrollo y gestión del contenido.
1 Dirección electrónic a: www.aichile.org/glosario
7
La facilidad de búsqueda.
La usabilidad y la accesibilidad.
El rediseño de la interfaz.
Teniendo en cuenta los conceptos dados por los autores mencionados, se llega a la conclusión de la importancia misma de la arquitectura, aspecto que se detalla en el epígrafe siguiente.
1.2.3 Importancia de la Arquitectura de Información
Está sustentada su importancia porque reduce o evita durante la elaboración de un producto de software
- Los costos de mantenimientos (gestión de contenidos y rediseños), es necesario que en el primer momento del Ciclo de Vida del Software se gestione de manera eficiente los contenidos que contendrá el mismo, esto evitaría tener que rediseñar tantas veces lo mismo; así como los costos de entrenamiento (retención del personal), es muy importante que el equipo de trabajo esté capacitado para la labor y que a su vez se sienta motivado por lo que está haciendo, cuestión que sería positiva para el software.
- Los costos de encontrar (tiempo y frustración), no es saludable elaborar un producto que se demore mucho tiempo, esto provocaría pérdida de dinero y frustración por parte del cliente y de los responsables de su realización; como la arquitectura de información estudia al cliente, conoce sus necesidades y sabe qué información y de qué manera es óptimo mostrarle la información, se emplea menos tiempo en el desarrollo del producto; esto no sucedería así, si no se tienen las nociones básicas de qué es y cómo quiere el usuario la información que solicita.
- Los costos de no encontrar (malas decisiones y otros canales), el objetivo de reducir o eliminar este costo es evitar que una mala decisión arruine el desarrollo del software.
- Los costos de construcción (personal, tecnología y errores), es muy importante que el personal conozca la tecnología con la cual trabaja, esto ayudaría a minimizar la cantidad de errores que se pudieran presentar y garantizaría la calidad del producto.
De manera conveniente si se reducen esos costos se garantiza que la información esté organizada y contextualizada, que permita aportar conocimientos, demostrando el Valor cognitivo; donde exista la relación Productos-Proyectos-Personas, que es el Valor educativo; y por último se garantice el Valor de Identidad al lograr que el producto final tenga la identidad del cliente, reputación y confianza.
8 1.2.4 Arquitectura de Información como proceso gerencial
Es conveniente decir que la Arquitectura de Información divide sus tareas de la misma manera que las cuatro etapas de la gerencia. Estas etapas son: Planificación, Organización, Ejecución y Control.
(Ronda León, 2005)
Planificación: Es la etapa donde se concibe el proyecto del producto. Es donde se realiza la definición de los objetivos (misión, objetivos...), el estudio de mercado y usuarios, la investigación temática y la selección de la información a utilizar y la definición de los procesos de la producción.
Organización: Es donde se diseña el producto. Se toma información suministrada en los pasos anteriores. Se establecen los procesos, además se organizan y representan los contenidos.
Ejecución: Es la etapa donde se realiza la programación y almacenamiento del producto (grabación, publicación, etc.)
Control: Es la etapa final donde se prueba el producto concluido. En esta fase se realizan las pruebas, test, controles de calidad.
Estas etapas se asemejan a algunos procesos y actividades del Ciclo de Vida de un Software planteado por RUP, por consiguiente la Arquitectura de Información también está presente en cada una de las fases, ocurriendo en determinadas disciplinas, y formando parte del desarrollo iterativo e incremental (desarrollo que se explicará en el transcurso de la investigación).
1.2.5 Arquitectura de Información y su relación con RUP
El Proceso Unificado de Software (RUP) es un proceso de software genérico que puede ser utilizado para una gran cantidad de Sistemas de Software, para diferentes áreas de aplicación, diversos tipos de organizaciones, niveles de competencia y tamaños de proyectos. (JACOBSON, y otros, 2000)
Esta metodología provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Al igual que la Arquitectura de Información, su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones (Figura 1) (UABC, 2007):
Un eje horizontal que representa el tiempo y muestra los aspectos del Ciclo de Vida del proceso a lo largo de su desenvolvimiento.
Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo con su naturaleza.
9 La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos.
La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.
Figura 1. Proceso Unificado
En su modelación se define como sus principales elementos:
Trabajadores (¿Quién?): Definen el comportamiento y responsabilidades (rol) de un individuo, grupo de individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo. Ellos realizan las actividades y son propietarios de elementos.
Actividades (¿Cómo?): Es una tarea que tiene un propósito claro, es realizada por un trabajador y manipula elementos.
Artefactos (¿Qué?): Productos tangibles del proyecto que son producidos, modificados y usados por las actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.
Flujo de actividades (¿Cuándo?): Secuencia de actividades realizadas por trabajadores y que produce un resultado de valor observable.
10 Los aspectos distintivos del Proceso Unificado están capturados en tres conceptos clave:
Dirigido por Casos de Uso
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios potenciales.
El término usuario se refiere no solamente a los humanos, sino a otros sistemas. En este contexto, el término usuario representa algo o alguien que interactúa con el sistema a desarrollar.
Un Caso de Uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los Casos de Uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el Modelo de Casos de Uso, el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación funcional del sistema. Una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿…por cada usuario? Estas tres palabras tienen una implicación importante, se fuerza a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo.
Aún cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso.
Por lo tanto, la arquitectura del sistema y los casos de uso maduran conforme avanza el Ciclo de Vida.
Centrado en la Arquitectura
El papel del Arquitecto de Sistemas es similar en naturaleza al papel que el arquitecto desempeña en la construcción de edificios. El edificio se mira desde diferentes puntos de vista:
estructura, servicios, plomería, electricidad, etc. Esto le permite al constructor ver una radiografía completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que está siendo construido.
11 El concepto de Arquitectura de Software involucra los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros involucrados, y tal y como están reflejadas en los casos de uso. Sin embargo, también está influenciada por muchos otros factores, como la plataforma de software en la que se ejecutará, la disponibilidad de componentes reutilizables, consideraciones de instalación, sistemas legados, requerimientos no funcionales, entre otros. La arquitectura es la vista del diseño completo con las características más importantes hechas más visibles y dejando los detalles de lado. El valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo el proceso, ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad y flexibilidad en los cambios futuros.
¿Cómo se relacionan los Casos de Uso con la Arquitectura? Cada producto tiene función y forma. Uno sólo no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso, función corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Por una parte, los casos de uso deben, cuando son realizados, acomodarse a la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realización de todos los casos de uso, hoy y en el futuro. En la realidad, arquitectura y casos de uso deben evolucionar en paralelo.
Iterativo e Incremental
Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o años. Es práctico dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es una iteración que finaliza en un incremento. Las iteraciones se refieren a pasos en el Flujo de Trabajo, los incrementos se refieren a crecimiento en el producto. Para ser más efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada.
Los desarrolladores basan su selección de lo que van a implementar en una iteración en dos factores. Primero, la iteración trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteración trata con los riesgos más importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteración anterior.
En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfagan los casos de uso. Si una iteración cumple sus metas
12 (y usualmente lo hace) el desarrollo continúa con la siguiente iteración. Cuando la iteración no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.
RUP también establece los siguientes flujos de trabajo:
Modelamiento del Negocio: describe los procesos de negocio, identificando quiénes participan y las actividades que requieren automatización.
Requerimientos: define qué es lo que el sistema debe hacer, para lo cual se identifican las funcionalidades requeridas y las restricciones que se imponen.
Análisis y Diseño: describe cómo el sistema será realizado a partir de la funcionalidad prevista y las restricciones impuestas (requerimientos), por lo que indica con precisión lo que se debe programar.
Implementación: define cómo se organizan las clases y objetos en componentes, cuáles nodos se utilizarán y la ubicación en ellos de los componentes y la estructura de capas de la aplicación.
Prueba: busca los defectos a los largo del Ciclo de Vida.
Despliegue: produce liberaciones del producto y realiza actividades (empaque, instalación, asistencia a usuarios, etc.) para entregar el software a los Usuarios finales.
Administración del Proyecto: involucra actividades con las que se busca producir un producto que satisfaga las necesidades de los clientes.
Administración de Configuración y Cambios: describe cómo controlar los elementos producidos por todos los integrantes del equipo de proyecto en cuanto a la utilización/actualización concurrente de elementos, control de versiones, etc.
Ambiente: contiene actividades que describen los procesos y herramientas que soportarán el Equipo de Trabajo del proyecto; así como el procedimiento para implementar el proceso en una organización.
Al analizar la Arquitectura de Información como proceso iterativo, se ubica dentro de RUP fundamentalmente en la Fase de Inicio, en el Flujo de Trabajo Modelamiento del Negocio mediante las siguientes actividades:
Identificar el objeto, propósito y fines del software.
Definir el público objetivo y los estudios de la audiencia.
Gestionar la configuración enfocado a las políticas de organización de la información dentro del proyecto.
Generándose artefactos como:
Documento de Necesidades de Usuario.
13
Documento de Características del Software.
La Arquitectura de Información se sitúa además en el Flujo de Trabajo Requerimientos a través de las acciones:
Prototipar Pautas de Diseño.
Prototipar Interfaces de Usuario.
Obteniéndose como artefactos:
Documento de Arquitectura de Información.
Unido a las actividades anteriormente dichas, la Arquitectura de Información también se encarga de definir las tareas: Diseñar la Navegación, Definir el Etiquetado (Ver Glosario de Términos) o rotulado de los contenidos para acceder a la información y además, de la Planificación, Desarrollo y Gestión de Contenidos.
1.3 El Prototipo de Interfaz
En el proceso de Arquitectura de Información aplicada a la Gestión de Contenidos en las Interfaces de Usuario de un software, es necesaria la Representación de la Información, para tener una idea de cómo quedará el producto final. Los Prototipos se utilizan en este momento para ilustrar cuál será la organización y estructuración visual de los diferentes elementos del futuro software, y con ello validar la propuesta con los Clientes y Usuarios finales.
Ahora bien, ¿Qué son los Prototipos?
Un Prototipo es una representación limitada del diseño de un producto, que permite a las partes responsables de su creación experimentar, probarlo en situaciones reales y explorar su uso. (La Calle, 2005)
Maner define que un Prototipo es un modelo (representación, demostración o simulación) fácilmente ampliable y modificable de un sistema planificado, probablemente incluyendo su interfaz y su funcionalidad de entradas y salidas (Maner, 1997). Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final: es una implementación parcial, pero concreta de un sistema o una parte del mismo. Principalmente se crean para probar cuestiones de Diseño Gráfico y Visualización sobre todo lo que vaya a mostrar el sistema durante su desarrollo.
Los prototipos constituyen además una herramienta muy útil para hacer participar al usuario en el desarrollo y poder evaluar el producto desde las primeras fases de este.
Existen varios tipos de Prototipos de Interfaces en dependencia de la utilización que se le vaya a dar a los mismos, como se explica en el sub-epígrafe siguiente.
14 1.3.1 Tipo de Prototipos
Existen fundamentalmente dos tipos de prototipos:
1. Prototipo Rápido (concept prototipe): es un mecanismo para lograr la validación pre- compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. En este sentido, el prototipo puede ser visto como una aceptación interna de que los requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación.
El prototipo rápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a "controlar" su constante evolución.
2. Prototipo Evolutivo: Desde una perspectiva diferente, todo el Ciclo de Vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos.
Tradicionalmente, el Ciclo de Vida está dividido en dos fases distintas: Desarrollo y Mantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y va en contra de la realidad, ya que la mayor parte del costo del software ocurre después de que el producto se ha entregado. El punto de vista evolutivo del Ciclo de Vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan ser nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final. La adopción de esta óptica elimina la distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimación de costos, enfoques de desarrollo y adquisición de productos.
Sin embargo existen otras clasificaciones de prototipos como por ejemplo:
Baja Fidelidad: conjunto de dibujos (por ejemplo, una presentación de escenarios) que constituye una maqueta estática, no computarizada de una interfaz de usuario para un sistema en planificación.
Alta Fidelidad: conjunto de pantallas que proporcionan un modelo dinámico, computarizado y operativo de un sistema en planificación.
Exploratorio: prototipo no reutilizable usado para clarificar las metas del proyecto, identificar requerimientos, examinar alternativas de diseño o investigar un sistema extenso y complejo.
Experimental: prototipo utilizado para la validación de especificaciones del sistema.
Operacional: prototipo iterativo que es progresivamente refinado hasta que se convierte en el sistema final.
Horizontal: prototipo que modela muchas características de un sistema pero con poco detalle.
Dicho detalle alcanzará una profundidad determinada, va a resultar especialmente útil en las etapas tempranas de diseño y tiene como objetivo el test del modo de interacción global, al
15 contemplar funciones comunes que el usuario va a utilizar frecuentemente.
Vertical: prototipo que modela pocas características de un sistema pero con mucho detalle. Va a resultar especialmente útil en etapas más avanzadas del diseño y tiene como objetivo el test de detalles del diseño
Diagonal: prototipo horizontal hasta un cierto nivel, a partir del cual se puede considerar vertical.
Global: prototipo del sistema completo. Prototipo horizontal expandido que modela una gran cantidad de características y cubre un amplio rango de funcionalidades. Va a resultar muy útil a lo largo de todo el proceso de diseño.
Local: prototipo de un único componente o característica del sistema de usabilidad crítica. Va a resultar de utilidad en algunas etapas específicas del proceso de diseño.
1.3.2 Niveles de Prototipado
Se puede hacer una clasificación de los principales tipos de prototipos, variando su grado de complejidad, de acuerdo con las características que consideren su operabilidad para realizar simulaciones. Estos niveles son:
Prototipos Estáticos: son aquellos que no permiten la alteración de sus componentes, pero sirven para identificar y resolver problemas de diseño. En esta categoría se incluyen las presentaciones sobre reproductores, papel u otro medio de visualización.
Prototipos Dinámicos: permiten la evaluación de un modelo del sistema sobre una estación de trabajo o una PC. Estos prototipos involucran aspectos de diseño más detallados que los prototipos estáticos, incluyendo la validación del diseño del sistema en términos de requerimientos no funcionales, por ejemplo de rendimiento (performance). El inconveniente es que para hacer prototipos dinámicos se necesita más tiempo y personal para realizar la tarea.
Prototipos Robustos: deben ser relativamente completos en la simulación de las características dinámicas de la interfaz (presentación de mensajes de error, entrada y edición de datos, etc.).
Esta categoría puede ser utilizada para validar los objetivos de diseño.
El nivel de sofisticación del prototipo debería incrementarse a lo largo del proceso de Diseño de Interfaz de Usuario. La información recopilada durante las tareas de Análisis del Sistema y la Especificación de los Requisitos del Usuario constituyen los datos claves para el proceso de prototipación que se explica detalladamente a continuación.
16 1.3.3 Fases en el Proceso de Prototipado
Se definen cuatro pasos en el proceso de prototipado de cualquier interfaz de usuario. Esos cuatro pasos se corresponden con la estructura básica de cualquier propuesta de Ingeniería de Requisitos. El primer paso es determinar las necesidades del sistema, y no es un estado diferente al de Levantamiento de Requisitos en el que por lo general, el Analista y el Arquitecto de Información se pregunta quién y para qué se utilizará el sistema. En esta fase, el modelado de interfaces se mueve desde la definición de requisitos al análisis, punto en el que se decide evolucionar todo o parte de un prototipo esencial a un prototipo de interfaz tradicional. Esto implica convertir los borradores, elaborados a mano, en algo más sustancial, que se traduce en Prototipos de Interfaz sustentadas en herramientas informáticas.
Mientras se identifican y determinan las necesidades de los distintos involucrados en el desarrollo se pueden transformar los Prototipos de Interfaz de Usuarios esenciales, si fueron creados, y empezar a desarrollar sketches (bocetos). Una transformación entre prototipo esencial y tradicional no tiene por qué poseer una asociación directa, en muchos casos unos y otros prototipos pueden ser completamente diferentes.
Una vez que se entienden las necesidades de interfaz de los involucrados en el uso y desarrollo del sistema, el siguiente paso es construir un prototipo. Usando una herramienta de prototipado o un lenguaje de alto nivel, se pueden desarrollar pantallas, páginas e informes que los usuarios necesitan.
Con la plataforma de interfaz seleccionada, se puede empezar el proceso de convertir aspectos individuales recogidos en los prototipos esenciales a los prototipos tradicionales. En este punto se pasa por la realización de sketches o directamente a la confección de interfaces. La realización de sketches involucra más a los usuarios.
No se necesita crear un prototipo para el sistema completo. Es muy habitual limitarse a prototipar una pequeña porción de la interfaz de usuario, quizás una simple pantalla o página HTML antes de proceder con la implementación. Debe tenerse también en cuenta que los desarrolladores trabajan siguiendo una filosofía evolutiva. Amén de que en algunos casos, y puntualmente, se tenga que prototipar una porción importante del sistema, se tratará de ejercicios de visionado o para ayudar a definir el alcance del proyecto y justificar los recursos económicos que se solicitan.
Una vez que el prototipo ha sido construido, debe ser evaluado o validado por los involucrados en el proceso de desarrollo con el fin de verificar que se contemplan todas las necesidades. Algunas veces esto es tan fácil como pedirle a alguien que gaste algo de tiempo mirando lo que otro ha construido y otras veces es tan complicado como fijar una reunión para discutir y presentar el desarrollo al grupo de
17 personas involucrada en el mismo. Cuando se evalúa un prototipo a nivel personal es útil hacerse preguntas como las siguientes:
¿Qué destacarías del prototipo elaborado?
¿Qué identificas como malo o controvertido?
¿Qué decisiones de diseño has considerado y qué se ha perdido en el camino?
Después de evaluar el prototipo, se puede necesitar partir, modificar o incluso enriquecer. También se puede dar por finalizado el proceso de evaluación de prototipo cuando no surjan nuevas ideas que considerar. En cualquier otro caso habrá que volver a capturar requisitos, volviendo a la primera etapa.
En el libro “The Object Primer” (El Primer Objeto) de ScottW Ambler (Ambler, 2004) sugiere los siguientes trucos y técnicas que le han sido útiles en su trabajo realizando prototipos:
Trabaja con usuarios reales.
Haz que los involucrados en el proceso de desarrollo trabajen con los prototipos.
Entiende el proceso real de negocio al que el sistema dará soporte.
Prototipa utilizando características que estés capacitado para desarrollar.
Consigue que alguien experto en interfaces te ayude a diseñar.
Explica qué es un prototipo y su utilidad.
Deja las decisiones de implementación para tan tarde como sea posible.
1.3.4 Objetivos del Prototipo
Siempre se debe establecer cuál es su objetivo pues el prototipo puede ser útil en diferentes fases del proyecto.
En la Fase de Requisitos los prototipos son usados para dar una visión general de cómo va a funcionar el sistema, de acuerdo con lo especificado en los Casos de Uso del sistema. Además de permitir que los usuarios aprueben dicha propuesta sin tener que implementar el software completo para enseñársela, esta retroalimentación facilita que se puedan cambiar o mantener funcionalidades de la aplicación de forma temprana.
En la Fase de Análisis de un proyecto se utiliza para obtener los requerimientos del usuario, su principal propósito es obtener y validar los requerimientos esenciales, manteniendo abiertas, las opciones de implementación. Esto implica que se deben tomar los comentarios de los usuarios, pero se debe regresar a sus objetivos para no perder la atención.
Por otra parte, en la Fase de Diseño se usa para ayudar a evaluar muchos aspectos de la implementación seleccionada, o sea verificar la factibilidad del diseño del sistema. Su propósito, basándose en los requerimientos previamente obtenidos, es mostrar las ventanas, su navegación,
18 interacción, controles y botones al usuario y obtener una retroalimentación que permita mejorar el Diseño de Interfaz.
1.3.5 Técnicas para la Aplicación de Prototipos
Si se desarrolla una Interfaz de Usuario confusa para un sistema, entonces no importará lo bueno o malo que sea el resto del sistema: los usuarios terminarán odiándolo, pues son precisamente ellos los que interactúan directamente con la Interfaz. Los desarrolladores consecuentes entienden al menos, y luego aplican, los fundamentos del desarrollo de Interfaces de Usuario. Esto implica la aplicación de algunas de las técnicas para ayudar a explorar la Interfaz junto con todos los involucrados en el proceso de Desarrollo, as í analizarán sus necesidades y entonces diseñarán interfaces que sean idóneas con ellas.
Existen cuatro técnicas fundamentales para elaborar Prototipos de Interfaces de Usuario:
Prototipo de Interfaz de Usuario Esencial: es un prototipo independiente de la tecnología, creado utilizando papel y puede ser usado para identificar requisitos de interfaz de usuario.
Un prototipo de interfaz esencial es el punto inicial de los prototipos de interfaz para desarrollar un sistema. Son modelos de baja-fidelidad de la interfaz de usuario que ofrecerá un sistema (Constantine, 1999). En estos prototipos se recogen las ideas que hay detrás de la interfaz de usuario, pero no los detalles exactos o concretos. Estos prototipos de interfaz de usuario sirven para recopilar e identificar los requisitos de la misma, independiente de la tecnología. En este sentido, son a los requisitos de interfaz lo que los casos de uso esenciales son a los requisitos de comportamiento.
Pantalla/informe sketch: es un borrador que muestra el diseño de los elementos principales de la interfaz, es decir, se utilizan pantallas, páginas HTML, o informes.
Prototipo de Interfaz de Usuario Tradicional: una interfaz de usuario que “funciona” y que presenta el sistema o parte del sistema a los usuarios; con frecuencia se crea para diseñar una interfaz de usuario en detalle.
Existen dos diferencias básicas entre el prototipado esencial y el tradicional. La primera es que el modelado esencial se centra en los usuarios y en el uso del sistema y no en las características del sistema. La segunda es que las herramientas de prototipado en el prototipado esencial son más simples, incluyéndose pizarras, papel y notas adhesivas. El uso de herramientas de prototipado electrónicas termina introduciendo condicionantes y prototipos que no son independientes de la tecnología como sucede con el prototipado esencial.
19 Cuando un equipo de trabajo crea un Prototipo Esencial de Interfaces de Usuario, éste itera a través de las siguientes tareas:
1. El equipo explora el uso del sistema y lo hace a través de diferentes medios. Primero, trabaja utilizando una pizarra sobre la cual discutir las ideas, parten de algún boceto o borrador inicial y se favorecen de la naturaleza dinámica que ofrece la pizarra para hacer entender y presentar la porción del sistema que se esté discutiendo en cada momento.
2. Modelado utilizando elementos de interfaz de alto nivel. Los elementos de interfaz de alto nivel, tales como pantallas o informes potenciales, pueden ser modelados utilizando papel. Se emplea el atributo potencial al referirse a las pantallas o informes para recalcar el hecho de que finalmente se trata de una pantalla o un informe real que dependerá de una decisión de diseño.
A cada página de papel se le dará un nombre y contendrá los elementos de interfaz de usuario de menor rango. El uso del papel tiene varias ventajas: pueden colgarse en una pared, son buenos para trabajar en grupo y que todos sean partícipes de su contenido e interactúen con ellos, son suficientemente grandes como para poner notas adhesivas en ellos, se puede escribir y se pueden guardar de una sesión de trabajo a la siguiente.
3. Modelar los elementos de interfaz de bajo nivel. Los elementos de interfaz de menor nivel, tal como campos de entrada y listas, se modelan utilizando notas adhesivas. En “Software for Use:
A Practical Guide to the Models and Methods of Usage-Centered Design” (Software para el uso:
Una Guía Práctica para los Modelos y Métodos de Uso-Diseño Centrado) (Constantine, 1999), el autor recomienda utilizar diferentes colores para los diferentes tipos de componentes, por ejemplo, colores brillantes/vivos (amarillo o rojo) para los elementos de interfaz activos como son los campos de entrada y colores más suaves o apagados (blanco o canela) para los elementos pasivos o de menor nivel.
4. Explorar la Usabilidad de la interfaz. Los sistemas altamente usables son fáciles de aprender, de usar, de recordar, se comenten pocos errores y hay una subjetiva sensación de satisfacción.
(Nielsen, 1993)
Diagrama de Flujo de Interfaz de Usuario: un diagrama que muestra los elementos principales de la interfaz y cómo los usuarios pasan de unos a otros; se usa para explorar la usabilidad (nivel alto) del sistema y para documentar y validar la interfaz.
El prototipado de interfaces de usuario es una técnica de análisis iterativa en la que los usuarios están involucrados de forma activa en el desarrollo de bocetos de interfaz para un sistema. Los prototipos de interfaces de usuario tienen varios propósitos:
20
Como artefacto de análisis, permiten explorar el espacio del problema con el resto de involucrados en el desarrollo.
Como artefacto de diseño, permiten explorar el espacio de la solución que ofrece el sistema.
Como vehículo de comunicación, facilitan el intercambio de opiniones y propuestas entre los involucrados en el desarrollo.
Como cimiento o base potencial permite sentar las bases sobre las que debe continuar el desarrollo del sistema.
Los prototipos de interfaz son un medio excelente para explorar la interfaz, pero desafortunadamente no es fácil hacerse una idea de “todo el cuadro” y muchas veces se quedan relegados a cuestiones de diseño. Los Diagramas de Flujo de Interfaz de Usuario también denominados Storyboards, Diagramas de Navegación entre Ventanas (Page-Jones, 2000) o Mapas de Navegación Contextual (Constantine, 1999), permiten modelar y reflejar las relaciones entre los elementos de interfaz de usuario.
Los diagramas de flujo de interfaz de usuario son útiles para dos propósitos. Primero, se usan para modelar las interacciones que los usuarios tienen con su software, como se define en los casos de uso. Segundo, permiten tomar conciencia del comportamiento de la interfaz de usuario a alto nivel.
Esta visión es la vista conjunta de todos los comportamientos reflejados en los distintos casos de uso identificados y es lo que se denomina visión arquitectónica de la interfaz de usuario. (Constantine, 1999) Debido a que los diagramas de flujo de interfaz de usuario ofrecen una visión de alto nivel de la interfaz de usuario del sistema, con ellos se logrará entender cómo se espera que el sistema funcione.
Además, el flujo de interfaz de usuario también sirve para determinar si la interfaz de usuario será usable o si el sistema será complejo de aprender y entender.
1.3.6 Estrategias de Diseño de Prototipos de Interfaces de Usuario Las estrategias para el desarrollo de prototipos son:
Prototipos para pantallas. El elemento clave es el intercambio de información con el usuario.
Prototipos para procedimientos de procesamiento. Incluye soloprocesos sin considerar errores.
Prototipos para funciones básicas. Sólo se desarrolla el núcleo de la aplicación, es decir, los procesos básicos. (Donadello, 2004)
Cuando se desarrollan interfaces de usuario se debe tener presente y considerar técnicas y principios básicos de diseño de interfaces de usuario. La experiencia demuestra que al utilizar dichas recomendaciones los resultados son mucho más factibles. Otra recomendación es que dentro del proyecto de desarrollo del sistema haya alguien que ejerza el papel de experto en diseños de interfaz
21 de usuario, que podría hacerlo la persona que se encarga de la Arquitectura de Información, por explicaciones que se dan en el epígrafe Rol del Arquitecto de Información. De otra forma esa labor deben realizarla desarrolladores habituales que no siempre tienen conocimientos suficientes sobre el tema.
Constantine y Lockwood (Constantine, 1999) describen una colección de principios básicos para mejorar la calidad del diseño de las interfaces de usuario. Estos principios son:
El Principio de Estructura. Los diseños deberían organizarse adecuadamente, modelos claros, consistentes que sean aparentes y fáciles de reconocer por los usuarios, donde se ubiquen las cosas relacionadas juntas, y separadas aquellas otras que no tengan nada que ver.
El Principio de Simplicidad. El diseño debería ser simple, las tareas habituales deben ser fáciles de hacer, presentarse de forma clara y simple, utilizando el lenguaje del usuario, y proporcionando una asistencia significativa.
El Principio de Visibilidad. Los diseños realizados deberían facilitar todas las opciones y material necesario para que una tarea pueda ser realizada sin distracciones o información redundante o innecesaria. Los buenos diseños no saturan o confunden al usuario con muchas alternativas o información superflua.
El Principio de Retroalimentación. El diseño elaborado debería informar al usuario de las acciones, cambios de estado o condición, de los errores que surjan o de las excepciones relevantes y de interés para el usuario a través de mensajes elaborados utilizando lenguaje claro, conciso, correcto y familiar para los usuarios.
El Principio de Tolerancia. Los diseños deberían ser flexibles y tolerantes al error, reduciendo los errores y permitiendo operaciones de hacer-y-deshacer.
El Principio de Reutilización. Los diseños deberían reutilizar componentes internos y externos y sus comportamientos. La consistencia debe primar en los diseños, esto facilita aprender y recordar los sistemas.
1.3.7 Papel del Prototipo
Son útiles para comunicar, discutir y definir las ideas entre los diseñadores y las partes responsables.
Los prototipos responden a preguntas y apoyan el trabajo de los diseñadores probando ideas, clarificando requisitos o definiendo alternativas. (La Calle, 2005) Es muy útil hacer uso del prototipo en la Fase de Análisis para prevenir algunos problemas que pudieran presentarse después en la Fase de Desarrollo. Con el prototipo pueden aparecer ciertas interrogantes que respondidas a tiempo evitarían un atraso en el proceso de desarrollo del software. El prototipo ayuda a comprender el funcionamiento
22 del sistema, a explorar sus funcionalidades y a que el usuario tenga una idea general de lo que va a hacer el producto para que de esta forma se pregunte si es eso realmente lo que quiere y no ocurra que al final el cliente quede insatisfecho y la aplicación no sea lo que realmente necesita. Brinda aportes de comunicación entre desarrolladores y clientes, logra un incremento de la participación constructiva del usuario, contribuye con el Aseguramiento de la Calidad, se reúne la mayor cantidad de requerimientos válidos, se hace una mejor Gestión de las peticiones de Cambios. (Maner, 1997).
1.3.8 Usabilidad
Un aspecto importante que debe considerarse cuando se desarrolla un prototipo de interfaz de usuario esencial o tradicional para un sistema, es la Usabilidad. Un sistema informático es usable cuando puede utilizarse para realizar una determinada tarea de forma eficiente. Centrándose en las aplicaciones para Internet, se podría decir que una web es usable cuando:
Aporta información relevante y frecuentemente actualizada.
Resulta fácil de aprender y recordar.
Permite realizar las tareas para las que fue diseñado de forma rápida y sencilla.
Genera pocos errores.
Proporciona una experiencia subjetivamente agradable.
La importancia de la usabilidad radica en: primero, al centrarse inicialmente en el uso y en la usabilidad en lugar de en las características o la funcionalidad del usuario, y en sus usuarios y en sus necesidades más que en las interfaces, los sistemas se pueden convertir en entes menos complejos , simples y más baratos. Segundo, los mejores sistemas son aquellos placenteros, satisfactorios y la gente se siente bien al utilizarlos, en definitiva, son usables. Tercero, los sistemas que son difíciles de utilizar suelen ser difíciles de aprender y más proclives al cambio y a la necesidad de mantenimiento.
Cuarto, conforme los usuarios se acostumbran a utilizar productos software se hacen más entendidos y exigentes y menos tolerantes a productos diseñados y elaborados de forma pobre.
1.4 Aplicaciones y Herramientas para Diseñar Prototipos
El prototipo actúa en varias fases del Proceso de Desarrollo del Software y en todas es importante por los obstáculos que soluciona en cada una de ellas. Es importante resaltar la necesidad de empezar a implementarlo aunque sea con un nivel menos complejo, desde etapas tempranas, es decir, desde la Captura de Requisitos, para comenzar a explorar las posibles dificultades que pudieran presentarse y llegar a la Fase de Desarrollo con ideas lo más claras posibles respecto al sistema a implementar.
