Toma de Requisitos – Paso 9: Requisitos no funcionales

Toma de Requisitos – Paso 9: Requisitos no funcionales

Hoy vamos a  finalizar esta serie de artículos sobre la toma de requisitos (algunos suspiraréis de alivio), explicando el último paso: la documentación de requisitos no funcionales.
Esta entrada forma parte de una serie cuyo índice es el siguiente:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez tenemos cerrado el prototipo, es importante cerrar la documentación de usuario (que representa sobre todo los requisitos de interfaz), pero también, es vital complementarlo con los requisitos no funcionales.

Las tareas realizadas en los Pasos 1 a 8 nos han permitido solventar proyectos basados principalmente en interfaz, proyectos más bien pequeños.

Sin embargo, siempre tendremos funcionalidades necesarias pero difíciles de plasmar en un prototipo o en un manual de usuario: los requisitos no funcionales. Aquí podemos encontrar entre otros:

  • Velocidad de acceso a la aplicación, o tiempos de respuesta.
  • Uso de memoria.
  • Interfaz con el sistema operativo o con otros sistemas (tanto hardware como software).
  • Algoritmos detallados con reglas internas de comportamiento (reglas de negocio).

¿Hay que hacer un documento con todo esto? Pues no del todo. Lo que hay que hacer es recopilar esta información para que no se pierda, y esto puede hacerse en varios sitios (seamos ágiles):

  • Como un anexo del manual de usuario
  • Como notas en una pizarra o post-its en la pared (que alguien se acuerde de hacerle una foto, antes de que se los lleve el viento!!)
  • Etc.

Finalmente, viene la parte más dura: hay que revisar, establecer una línea base, y poner bajo control de cambios este documento/foto/pizarra.

  • Revisar: siempre viene bien, 4 ojos ven más que 2. Si programar entre pares produce buen código…¿porqué no revisar más de una persona los documentos?
  • Línea base: hay que dejar claro un punto de partida. Difícilmente sabremos llegar a ningún sitio si no tenemos claro cuál era nuestro punto de origen.
  • Control de cambios. No pongáis la cara que suelen poner la gente en mis proyectos cuando les cuento esto. Control de cambios podría ser hacer una foto nueva a la pizarra cada vez que cambiamos los post-it, o guardar el documento en subversion y guardar una nueva versión cada vez que lo modificamos.

Y esto ha sido todo. Para finalizar, decir que estos 9 puntos no indican COMO ha de ser una toma de requisitos. Es tan sólo una aproximación para hacerlo, orientada a proyectos en los que sea primordial contar con un prototipo, exista un cliente involcurado, predominen los requisitos funcionales sobre otros, etc.

Como ya creo haber comentado en algún otro post anterior, estaría relacionado con la metodología UIDD (o User Interface Driven Development), donde lo primero que se hace es la interfaz, y se va propagando el desarrollo a otras capas o partes del sistema. Ojo, no significa esto que la interfaz esté cerrada. Recordad que la realidad siempre estará en contra nuestra, y lo más probable que cambie…sea lo más estable y asentado que tengamos. Gracias Sr. Murphy por tu ley.

Anuncios

Toma de Requisitos – Paso 8: Escribir documentacion de usuario

Toma de Requisitos – Paso 8: Escribir documentación de usuario

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 8: escribiendo una documentación de usuario detallada, basada en el prototipo que completamos enel paso 6 y que establecimos en el paso 7 como línea base de los requisitos.

Esta entrada forma parte de una serie:

  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez tenemos cerrado el prototipo, es importante cerrar también, lo antes posible, una documentación de usuario (requisitos, manual de usuario, etc).

Muchos pensaréis: “venga ya. ¿ahora vamos a documentar? ¿No basta con el código?”. De esto ya hemos hablado en otros posts: “Nos gusta programar pero no documentar“. Hay varios motivos para hacerlo:

  • Porque lo pide el cliente (sí, en multitud de pliegos, concursos públicos, etc., se exige documentación).
  • Porque lo necesita el cliente (sí, de nuevo, los manuales se necesitan, como se necesita una rueda de repuesto. Y eso es así, aunque la rueda de repuesto, al igual que el manual, quizá no se lleguen a usar).
  • Porque el cliente no se va a leer tu código cuando tenga que hacer algo y no sepa cómo, o cuando algo no funcione como el usuario cree que debe hacerlo.
  • Porque cada vez que el cliente quiere negociar o revisar el avance del proyecto, no se va a leer tu código para ver cómo va a funcionar todo cuando esté: lo que se revisa son los requisitos o un manual provisional.

Bueno. Sigamos. Aunque normalmente se documenta al final, en nuestra aproximación, lo haremos al principio. ¿Porqué? Pues porque estamos haciendo una toma de requisitos, y la mejor forma de hacerlo es dejando los documentos por adelantado.

Es más fácil para el equipo de desarrollo consultar el manual a la hora de hacer unas pruebas, o de avanzar el desarrollo, que cualquier otra cosa. Quizá el usuario no se lea el manual, pero al menos los programadores y los testers sí deberían estar hartos de leerlo. Probablemente el usuario no se lo lee porque los manuales que solemos hacer son siempre “fuera de hora”: los hacemos en ese tiempo que hay al final del proyecto, y porque nos obligan, y siempre es en horas muertas, o cuando ya estamos reventados de intentar sacar adelante una funcionalidad que ya va retrasada. Por cierto, esa funcionalidad tal vez no estaría retrasada si no hubiéramos tenido que rehacer 20 veces el producto…y eso ocurría (tal vez), si nos hubiéramos molestado en hacer un manual de usuario al principio (como aquí planteo).

Otra ventaja de hacer la documentación y manuales al principio, evita tener que hacer una especificación técnica detallada. Ya se indica cómo debe funcionar todo, ya están los requisitos…¡pues a programar!

El cliente y usuarios finales entenderán mucho mejor un manual, y seguro que si es el mismo que usan (y revisan y corrigen) los programadores en el día a día, será un manual útil, y no el típico ladrillo que se suele hacer y que nadie lee.

El tener una documentación completa tan temprano, pule aún más posibles inconsistencias y puntos “oscuros” que pudieran haber quedado en nuestro prototipo. Se evitan muchas veces el tener documentos demasiado técnicos. En su lugar, se está haciendo una documentación basada en el uso, en la funcionalidad, no en la tecnología.

Este tipo de documentación, se va a mantener y a actualizar, mucho mejor que cualquier otro tipo de documento. Puesto que es algo que todo el mundo usa y necesita tenerlo al día: los usuarios finales, los programadores, los analistas, los testers…es como el anillo de la película del señor de los anillos: “un documento para unirlos a todos…”.

Este tipo de documento es práctico, sin rollos que pretendan artificialmente hacerlo ameno, o inteligente, o complejo. Dice lo que el usuario necesita que el software haga. Y punto.

En este documento, como hemos dicho, se especifica (como si fuera un documento funcional), el QUE, pero no el COMO.

Pero además, este tipo de documentación da a los programadores libertad y creatividad para resolver técnicamente las cosas como mejor les parezca. Y de esta forma, es mucho más fácil que acabe creando software que cumpla lo QUE necesita el usuario.

Un saludo.

Toma de Requisitos – Paso 7: Prototipo como Requisitos 1.0

Toma de Requisitos – Paso 7: Prototipo como Requisitos 1.0

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 7: establecer el prototipo como la primera versión de los requisitos.

Esta entrada forma parte de una serie cuyo índice es el siguiente:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez llegados a este punto, tendremos un prototipo bastante completo. Pero…¿No se trataba de tomar los requisitos? ¡Pero si ya los tenemos! Basta con considerar el prototipo como la primera versión de los requisitos.

Para ello, el prototipo debe cumplir una serie de características:

  • Debe ser estable.
  • Debe haber un compromiso por parte del equipo de desarrollo de hacer el software realmente a imagen y semejanza del prototipo.
  • El cliente, o al menos los usuarios clave, han de validarlo.
  • Debe ponerse al prototipo bajo control de cambios. No podemos modificarlo a la ligera. Un cambio en el estilo, en el flujo, en la funcionalidad…nos puede provocar una tormenta imparable de cambios.

A partir de aquí, basaremos todo en el prototipo, de forma que sirva de base para crear:

  • Las estimaciones.
  • Los planes.
  • La estructura y organización del equipo.
  • Los diseños.
  • EL desglose del trabajo que permita construirlo.

Y aquí da igual la metodología que usemos. Sea ágil o no, hay que aceptar los cambios en el prototipo, como parte de los cambios que se requieren para el producto final.

El control de cambios no significa “ya está”, “ya lo tenemos y no hay que tocarlo”. Pero sí significa que tenemos que estar atentos a cada cambio, y realizar el adecuado seguimiento antes de aceptarlo, rechazarlo, o ponerlo “en espera”. Ya dedicaremos un día algún artículo más detallado al control de cambios, y algunos trucos al respecto que espero os sean útiles.

Por desgracia, la manera más común de tratar los cambios es aceptar todo sí o sí, desbaratando cualquier plan existente, y evitando realizar nuevos planes, que al final, pudieran habernos llevado al éxito. Por desgracia, es así en demasiadas ocasiones. Y es que nos ciega el éxito, nos da miedo involucrar al cliente y realmente llevar un buen control de cambios. En fin.

Una vez tenemos la primera línea base del prototipo, la primera versión por tanto de los requisitos, tendremos una serie de logros adicionales:

  • Posibilidad de empezar con la documentación de usuario (manuales, etc).
  • Preparar los planes de pruebas, con todo detalle.
  • En paralelo, también pueden comenzar la arquitectura, diseño y algunas tareas de implementación.

En el siguiente post de esta serie, veremos ya la creación de documentación, y la toma de requisitos no funcionales.

Un saludo.

Toma de Requisitos – Paso 6: Completar el prototipo

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 6: completar el prototipo.

Esta entrada forma parte de una serie cuyo índice es el siguiente:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez hemos llegado a este punto, y tenemos una guía de estilo en condiciones, podremos pasar a completar el prototipo hasta hacerlo totalmente funcional.

Ojo, no estamos diciendo que el prototipo se acabe convirtiendo en la aplicación final. Esto ha sido ampliamente discutido en muchos foros, y tiene sus defensores (especialmente en el ámbito del software ágil) y sus detractores (especialmente desde el punto de vista de la ingeniería del software).

De esta forma, se consigue que los desarrolladores tengan una visión completa de lo que será el producto final. Hay dos visiones:

  • La visión del producto permite alinear el trabajo de los desarrolladores.
  • El prototipo detallado permite una visión mucho más detallada, facilitando a los desarrolladores el trabajo.

El prototipo, llegados a este punto, deberá ofrecer toda la funcionalidad del software, con al menos:

  • Todos los cuadros de diálogo, incluyendo los cuadros de diálogo estándar como Abrir, Cerrar, Imprimir, Guardar, etc.
  • Todas las pantallas de inserción de datos.
  • Todas las salidas de datos (pantallas, informes, listados…)
  • Todas las interacciones con el sistema operativo (ejemplo: importación y exportación al portapapeles).
  • Interacción con sistemas externos y otros productos de terceros.

El prototipo contendrá por tanto las principales interfaces:

  • Con el usuario
  • Con el sistema operativo
  • Con otros sistemas externos

Llegados a este punto, tendremos que hacer una línea base (no olvidemos la gestión de la configuración, que sea un prototipo-borrador no significa que debamos correr el riesgo de perderlo!!).

Tal y como establece Steve McConnell en su magnífico libro Software Project Survival Guide:

“No deberías usar un prototipo como la base de software real, así como no deberías usar un decorado de Hollywood como base para una casa de verdad”.

El prototipo es un callejón sin salida, útil, pero un callejón sin salida. No ha habido una arquitectura, no está preparado para construir sobre él la aplicación final. La mayoría de autores recomiendan construir el prototipo en un entorno y en un lenguaje de programación que facilite el desarrollo rápido, pero que claramente no vaya a usarse en el desarrollo final. Por ejemplo, úsese Visual Basic o un lenguaje similar de alto nivel, cuando el desarrollo final vaya a ser en Java o C++ o C#. Esto evitará tentaciones más adelante.

Toma de requisitos – Paso 5: Crear una guía de estilo

Hoy vamos a ver el paso 5º de la guía sobre toma de requisitos.
Esta entrada forma parte de una serie cuyo índice es el siguiente:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Los usuarios han aceptado y validado el prototipo (sí, eso fue el Paso 4 anterior). Así que ahora, los programadores deberían crear una guía de estilo: un pequeño manual o guía que identifique los estándares de estilo a seguir durante el inminente desarrollo software.

A ver, que esto no es una metodología: no hacen falta 200 páginas. Ni 20. Seguramente, con un par de páginas será suficiente. Habrá que añadir:

  • Estilos visuales
  • Imágenes con las pantallas más representativas (los 2 o 3 tipos de pantallas o cuadros de diálogo a mostrar).
  • Ubicaciones de los botones, incluyendo los más habituales (Aceptar, Cancelar, etc).
  • Estilos visuales: efectos, colores, tipos de letra.
  • Mensajes de texto a mostrar. Se trata de buscar una terminología común, que todos los conceptos tengan un nombre único, usado de forma consistente en todas las pantallas, y sea un nombre familiar en el contexto del negocio del cliente.
  • Estándares existentes a los cuales nos vamos a adherir sobre todo a nivel de usabilidad y accesibilidad.

Por supuesto, tras completarla, deberá revisarse y hacer una línea base (ponerla bajo control de cambios). Para esto no hace falta nada del otro mundo: un subversión o un repositorio similar bastarán.

Los estilos visuales, cuanto antes sean definidos, más fácilmente lograrán que haya consistencia en la interfaz de usuario. Después de todo, los requisitos cambiarán. Pero el aspecto visual ,es un buen sitio por el que empezar como base.

Para finalizar, van algunos estándares o normas relacionadas con los interfaces:

  • ISO/IEC 9126: evaluación de productos software.
  • ISO 9241: requisitos ergonómicos para trabajar con terminales de presentación visual (VDT)
  • ISO/IEC 10741: interacción de diálogos.
  • ISO/IEC 11581: símbolos y funciones de los iconos.
  • ISO 11064: diseño ergonómico de centros de control.
  • ISO 13406: requisitos ergonómicos para trabajar con presentaciones visuales basadas en paneles planos.
  • ISO 13407: procesos de diseño centrados en la persona para sistemas interactivos.
  • Guías de estilo para la web: IBM, W3C

Toma de requisitos – Paso 4: Presentar el prototipo

Hola, hoy vamos a ver el paso siguiente (Paso nº 4 en nuestra secuencia) en la definición de los requisitos, y para ello, tendremos que presentar a los usuarios, el prototipo que con tanto mimo hemos creado.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

En primer lugar, hay que hacer notar que la primera versión de un prototipo difícilmente va a gustar a los usuarios. Es algo normal, sus expectativas no van a cubrirse en esta primera versión.

Lo que hay que buscar en realidad es el feedback de dichos usuarios clave: sus comentarios son oro. Y lo son, porque tan sólo cuando esos usuarios ven el prototipo, la maqueta de nuestra aplicación, es cuando van a darse cuenta de detalles que habían pasado por alto, de información que difícilmente podría ser obtenida de otra manera.

Por supuesto, a los usuarios hay que dejarles claro que es un prototipo: ni hemos tenido un avance del 40% del proyecto en dos días, ni los problemas que vayan a surgir en la revisión han de ser tenidos en cuenta. Hay que tranquilizar a los usuarios en este sentido: aún estamos muy lejos de cerrar el prototipo, y por tanto, aún más lejos de tener avanzado el desarrollo del producto.

Es en esta fase cuando tendremos que hacer un auténtico ejercicio de usabilidad: conseguir no sólo que los requisitos se satisfacen, que han sido correctamente identificados. Además de esto, el producto debe ser sencillo, lógico, fácil de usar.

Es importante notar que en esta fase, hay que estar volcado al 100%, y hay que tener experiencia en el área que estamos prototipando. Si no es así, ni va a ser sencillo de usar, ni tampoco va a satisfacer las necesidades de los usuarios.

El objetivo final de esta fase es conseguir el apoyo, la excitación de los usuarios al lograr consciencia de que efectivamente, hemos entendido sus necesidades, y además, el producto va a facilitarles el día a día. No se trata de “satisfacer requisitos”, sino más bien de satisfacer a los usuarios finales.

En esta fase, puede pensarse que se está perdiendo un tiempo precioso en algo que va a tirarse a la basura. Después de todo, ese es el final de todo prototipo. Nada más lejos de la realidad. Al contrario, todo el esfuerzo invertido facilitará y acelerará el desarrollo posterior, evitando problemas, revisiones, y cambios de última hora.

Como ya he comentado, es fundamental aclarar a los usuarios que el producto es un prototipo, un mero “esbozo” de la realidad que aún está por construir. Por eso, al final, vuelve a servir lo que comentaba en el artículo anterior, en el paso 3: las herramientas de prototipado simples como el Paint o PowerPoint, o un dibujo en un papel, son mucho más efectivas. Esto es así porque el usuario las percibe como algo realmente temporal, no aprovechable. Si nos liamos a hacer mucho código, HTML, css, JavaScript, menús desplegables, etc, etc el usuario pensará que lo que está probando es ya un producto real. Después de todo, se instala, se usa, y da resultados como un producto real. Si caemos en la trampa de dar un prototipo demasiado realista, el cliente pasará a meternos presión, ya que pensará que le estamos engañando, y que en realidad, tenemos ya avanzado buena parte del desarrollo.

Es importante dar también una fecha límite a la fase de revisión del prototipo: 2 o como máximo 3 revisiones de prototipo, deberían ser suficientes. Si nos alargamos en su revisión, sí que podremos poner en peligro el plan general del proyecto.

Si quieres volver al índice haz clic en: Índice.
También puedes ir al paso anterior de la toma de requisitos haciendo clic aquí: Paso anterior.

Toma de requisitos – Paso 3: Cómo hacer un prototipo

Para que tu prototipo sea a prueba de idiotas…busca uno

Hacer un prototipo no es tan fácil como parece. Conviene seguir unas reglas, para que a la hora de continuar el desarrollo, no nos encontremos con problemas. Veamos un poco de qué hablo.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Simple.

El prototipo ha de ser simple. Se trata de ofrecer al usuario alternativas, de que pueda explorar cómo va a ser el sistema. Es por tanto el momento de explorar, de ofrecer opciones en cuanto a usabilidad, estilos, etc.

Alcance.

Se trata de ahorrar esfuerzos. No hace falta explorar todas las posibilidades, de abordar todos los casos de uso. De ofrecer todos los mensajes de error. De lo que se trata es de que el usuario reciba suficiente feedback de cómo se va a comportar el sistema. Para ello, hay que definir un alcance limitado, para que los esfuerzos de desarrollo también lo sean.

Por ejemplo, nos limitaremos a realizar los principales casos de uso. Es más interesante que cubramos una operación completa de varias pantallas, que por ejemplo cubrir una acción en cada pantalla.

El usuario no va a ser consciente de que funciona todo o parte en cada pantalla. Lo importante es que hemos cubierto una parte mayor de la aplicación. Por ejemplo, en un ERP haremos un alta en almacén, un alta de cliente, un alta pedido de ese cliente, y facturaremos ese producto para finalmente, contabilizarlo. Un caso de uso simple de cada pantalla, de forma que se cubra una gran parte del sistema.

Es más importante obtener la visión del look&feel, de qué se hace y cómo.

Herramientas.

¿Qué herramientas utilizar?Las más simples. Podría utilizarse HTML puro y duro en lugar de Java o código .Net. Pero tampoco es descabellado prototipar con herramientas más cercanas al diseño como Visio, Powerpoint o el mismísimo Paint que viene de serie en Windows.

¿Porqué no usar algo más elaborado como una herramienta profesional de prototipado? Pues porque precisamente en esta etapa, y los seguidores de las metodologías ágiles lo sabrán muy bien, no sirven mucho. Y no sirven, no porque sean malas, sino porque en esta etapa los requisitos aún son muy volátiles. Estas herramientas de prototipado pretenden ahorrar esfuerzo posterior, creando un sistema aprovechable. Sin embargo, el sistema no se va a aprovechar. El gran número de cambios lo echaría atrás. Claro, esto no ocurre cuando los requisitos tengan poca volatilidad. En ese caso, el sistema sí que puede prototiparse con herramientas que nos permitan en el futuro aprovechar los flujos, la estructura, o incluso el código.

Una recomendación: por simple que sea nuestro prototipo, si tiene código, siempre puede tener un error. después de todo es un prototipo. ¿Vamos a poner código de gestión de errores? ¿De logging? ¿Y qué más? ¡Si no hace falta! Queremos mostrar qué se va a hacer, nada más. Una pantalla Powerpoint, una imagen hecha con una herramienta de dibujo rápido, sería suficiente. Que la herramienta haga el trabajo por nosotros: para pasar de una pantalla a otra, usemos las acciones de Excel, de Powerpoint por ejemplo.

Otra ventaja de los prototipos hechos como “documento”, es que difícilmente tienen errores. No dependen del PC en que se van a ejecutar. Se pueden mandar al cliente, ejecutar directamente desde un correo, sin instalación. Ni siquiera hace falta que se copie una carpeta con código HTML en el escritorio. Con que esté instalada la aplicación (Word, Excel, Powerpoint…es suficiente). Con algunos productos, es posible convertirlos en “ejecutable”, de forma que en cualquier PC con Windows funcionen.

Detalles.

Los detalles, hay que cuidarlos pero con mínimo esfuerzo. ¿Que hay que sacar un informe al pulsar el botón “Imprimir”? Pues se muestra un documento de texto simulando el informe, o se muestra una imagen que muestre un informe típico.

Si queremos ahorrar esfuerzo mostrando datos encolumnados, nada más simple que usar una Excel, pegar ahí los datos a mostrar, y al ocultar la cuadrícula de fondo…¡premio! Tenemos un report simulado. También podemos simular la paginación, poniendo imágenes en celdas de forma que parezcan el botón “siguiente”, y que dicho botón sirva de hipervínculo a la página siguiente del informe (también simulada, por supuesto).

Esfuerzo

Con todo lo dicho, hay que conseguir máximo en diseño, estilo y apariencia…pero con el mínimo esfuerzo. Si los datos son fijos, o se muestran en una imagen, no importa. Pero el esfuerzo por pantalla o acción debe ser el menor posible.

Es muy importante repartir adecuadamente el esfuerzo durante el prototipado. Si contamos con equipo que conozca el diseño gráfico, utilicémoslo. Si alguien conoce Powerpoint y su facilidad para crear vínculos y botones que nos lleven de una slide a otra…adelante. Es mejor que el equipo se sienta a gusto y explote una herramienta, que nos perdamos intentando usar la última “mega-herramienta-de-prototipado” del mercado.

La profundidad funcional ha de ser muy liviana. Si dedicamos por ejemplo más de 1h por pantalla, ya es demasiado. Mejor centrarse en pintar el aspecto y que “de el pego”, que dedicar la hora a cargar datos XML y aplicar una hoja de estilos.

Como veo que el artículo me está saliendo muy largo, si no os importa, dejaré para una segunda parte todo lo que tengo en mente seguir contando sobre los prototipos.

Para ver el índice de artículos sobre Toma de Requisitos, haz clic aquí.
Para ir al paso anterior (nº2: Entrevistas), haz clic aquí.