El fin de los mensajes de error

error-messageLeía en linkedin un artículo de opinión (Error Messages are Evil), y mi sorpresa ha sido mayúscula al encontrar que se había formado todo un terremoto de respuestas, una pequeña polémica. Y mi sorpresa ha sido aún mayor al encontrar a gente joven entre los que responden en contra de la opinión del autor. En el artículo, el autor (Don Norman), defendía que los mensajes de error son el mal, y mostraba como ejemplo un mensaje de error ofrecido por una aplicación.

Yo esperaba que los usuarios más jóvenes apoyaran por fin estos conceptos de usabilidad, pero parece que al menos entre los lectores del artículo, no era así.

Y sí, estoy de acuerdo, los mensajes de error son malignos. Realmente, hay que erradicarlos. Ya lo comentaba hace tiempo Alan Cooper, uno de los maestros del UX en “The inmates are running the asylum”. Los mensajes de error tradicionales violan las reglas de la usabilidad:

  • Hacen sentir estúpido al usuario, al culparle por no saber usar el software.
  • Distraen del objetivo del usuario, que no es usar el software, sino obtener resultados.

¿Por qué decimos al usuario lo que hay que hacer DESPUÉS de que lo haga? ¿Porqué asumimos que es un error algo como un texto mal introducido? ¿Porqué no nos centramos en guiar al usuario a cumplir sus tareas en lugar de obsesionarnos en que use “correctamente” nuestro software?

Pues porque al desarrollar software, caemos en la trampa del egoísmo. Sólo pensamos en nosotros mismos, de forma que cuando el usuario no hace lo que nosotros queremos/esperamos…es SU culpa! Malditos usuarios…

Bueno, no puedo irme sin recomendaros no sólo el artículo de opinión en sí, sino esa gran obra  pionera en el mundo del UX (User Experience) que es “The inmates are running the asylum”.

Anuncios

La vuelta al trabajo y algo de usabilidad

Bueno, ya hemos vuelto al trabajo. En realidad hace tiempo que había vuelto, y aunque tengo (oh Dios mío) 30 post empezados sin terminar, no me he sentido con fuerzas de completar ninguno, y he preferido empezar uno nuevo.

Ha sido una época de mucho trabajo, grandes responsabilidades, dedicación, compromiso y sacrificio. Desde mi último post hemos renovado una certificación ISO 9001, hemos ampliado el alcance a toda la organización de un CMMI nivel 3, y para no aburrirnos, estamos cambiando completamente toda la metodología de trabajo para alinearnos todavía más a nivel mundial con el resto de la firma.

Dicho así que bien suena, eh? Uf. Ahí han quedado muchas noches, días y sufrimientos. Pero bueno, estamos de vuelta en el blog, y qué mejor forma de volver que ofreciendo conclusiones de hechos que creo nos afectan a todos y además de forma grave y sensible.

Blogs y Google+: un camino de ida y vuelta

Hace ya un tiempo que Google decidió ofrecerme en este blog el publicar los posts a través de google+. Leí la letra pequeña, pero no vi nada raro. Más bien, como descubrí después, la trampa estaba en lo que no se decía. Los comentarios dejaron de funcionar. Simple y llanamente, era físicamente imposible que mis lectores publicaran comentarios. Me encontré con que solamente podía obtener comentarios si publicaba en google+ y se me comentaba desde google+.

No es que tenga muchos comentarios en este blog, y a decir verdad, tampoco es algo que necesite. Como he dicho una y mil veces, yo no vendo. No me promociono. Y no pretendo que este blog os convenza de absolutamente nada. Si mi experiencia no os convence, podéis mirar por la web y encontrar miles de sinvergüenzas dispuestos a contaros su versión de la verdad a cambio de algún beneficio. Allá vosotros.

El caso es que esa conversión a Google+ me dejó prácticamente sin comentarios. Y los pocos comentarios, debía de responderlos a través de una red social que me era ajena. Yo no empecé este blog para hablar a un público limitado. Yo esperaba dejar una información útil que cualquiera podría leer y comentar mi blog, buscando siempre un conocimiento compartido y honesto. Y me cansé. Y dejé de usarlo. Incluso me cansé del uso de mi móvil android, que parecía obsesionado en obligarme a usar su red social una y otra vez.

Recientemente, he descubierto que las cosas han cambiado. Ya he recuperado la opción de que comenten mi blog a través de comentarios normales, sin pasar por ninguna red social. Pero en el camino me he desencantado un poco. Incluso he cambiado de sistema operativo en mi móvil, lo que comentaré otro día, puesto que ha supuesto una más que grata sorpresa. Gracias Windows Phone por ofrecerme un sistema pensado para que yo haga lo que necesito, no para que yo haga lo que necesita la empresa X.

No me queda claro qué ha pasado. No sé si los comentarios en mi blog están todos en Google+ (juraría que no), pero parece que tampoco están en este blog. Supongo que algunos se han perdido por el camino. Nadie me lo ha dicho, y no espero que me lo diga. Pero hablábamos de usabilidad, y aquí es donde he de decir que me siento cansado de ver cómo grandes empresas, toman decisiones puramente egoístas, pisoteando intereses con tal de obtener sus objetivos. Y lo hacen pisoteando la usabilidad en favor de supuestos beneficios que ellos obtienen, aunque perjudiquen claramente al consumidor.

Ahora me encuentro de nuevo aquí, con casi 200 post publicados (198 para no mentir), 30 post pendientes de publicar (en borrador), y nada menos que más de 100.000 entradas. Qué barbaridad. ¿Y qué hago yo ahora? Pues yo no sé vosotros, pero yo simplemente voy a seguir contando aquí cosas útiles o interesantes (para mí lo son al menos).

Hasta la próxima.

La doctrina del comentario

Hoy voy a hablar del comentar o no comentar el código, que parece que se está convirtiendo en una doctrina.

¿Qué es lo que ocurre? Vengo observando un tiempo la tradicional defensa del comentario como algo necesario, pero que hay que controlar en tamaño (nº de comentarios respecto al código), forma (estándares), etc.

Por otro lado, está la defensa a ultranza de la total ausencia de comentarios. Ojo, porque aquí sí que se suelen excluir los comentarios JavaDoc o NDoc que suele haber al principio de las clases y que se utilizan principalmente para documentar el código. Esto, menos mal, parece que nadie lo pone en duda (o al menos, no he identificado un grupo que esté por la labor de eliminarlo).

A continuación, veremos algunos argumentos o doctrinas que la gente utiliza en sus blogs en internet, y que me parecen interesantes. No los copio aquí para ensalzar ni tampoco ridiculizar a sus autores, sino sólo para intentar entender este tipo de argumentos y poder entender de qué hablamos. El objetivo no es tanto quitar la razón a los que están en contra de los comentarios, sino más bien entender el porqué de su postura, y tratar de ir un poco más allá. Yo de momento, sí me declaro abiertamente defensor de comentar el código, aunque luego hablaremos de con qué matices (mmm veo que de aquí tengo material para otro artículo de enfermedades del software: la “comentaritis”). Siempre creo que “menos es más”.

Frases en contra o a favor de los comentarios que podemos encontrar por la web:

  • Usar comentarios va en contra de mis principios.
  • los comentarios son siempre “el patito feo” del código fuente, cuando en realidad son tan importantes como el resto
  • comentar antes de programar, es lo que todo programador debe hacer. No puedes lanzarte a programar sin saber lo que quieres lograr.
  • al desarrollador por lo general no nos gusta “perder el tiempo” comentando y mucho menos documentando
  • si lo he hecho yo, ya sabré porqué lo he hecho
  • los comentarios en el código son algo completamente inútil que no hacen más que entorpecer y causar problemas
  • Cuando el código es modificado, tenemos que modificar también los comentarios, pues corremos el riesgo a explicar algo que no es lo que estamos haciendo. Ya bastante trabajo resulta mantener un código para también tener que mantener un paquete de oraciones.
  • Provocan problemas culturales, ya que muchas veces los comentarios están en un idioma diferente al que es capaz de leer el desarrollador actual, o en la mejor intención de hacerse entender, el “escritor” dejó una lista de oraciones sin concordancia, sentido, y con cientos de faltas de ortografía y errores gramaticales.
  • El que un comentario parezca necesario es signo de que el código no es lo suficientemente claro. Un buen código debe siempre explicarse por sí mismo sin necesidad de un “bastón” (o comentario).
  • Reducen la claridad en el código. ¿Alguna vez han visto un método con 50 líneas de las cuales menos de 10 son de código y lo otro es todo un tratado científico? Yo sí, y resulta un verdadero dolor de espalda descubrir las líneas reales ejecutables entre tantas palabras
  • Esta técnica de crear métodos para aislar secciones de código y dejar bien clara su función es extremadamente útil para aumentar la claridad. En vez de tener un módulo con 500 líneas ejecutables, podemos dividirlo en varios métodos cuya responsabilidad esté bien delimitada. El resultado final será mucho más claro y flexible.
  • los comentarios son la prostitución de las incapacidades de un programador.

¿Qué radicales son algunos de los comentarios, verdad? Y no es para menos. Por desgracia, es frecuente encontrarse programadores poco experimentados en los equipos que acaban sufriendo de “comentitis”: lo llenan todo de comentarios por su inseguridad y falta de método. Aquí os recomendaría los que a mi modo de ver son dos libros indispensables tanto para programadores que se creen experimentados, como para los que empiezan. (Creedme, nunca seremos suficientemente experimentados, y lo que es peor, el paso del tiempo, la destreza se pierde). Los libros son:

  • Code Complete, de Steve McConnell
  • Clean Code, de Robert C. Martin

Dejaremos para otro día unas recomendaciones sobre qué y cómo comentar, y porqué. Ahora vamos a dar un breve repaso a algunos consejos para evitar que nos afecte:

  • No podemos controlar todo lo que hacen los demás. No podemos exigir que respeten nuestra forma de trabajar si no respetamos la de los demás. No todo el mundo tenemos el mismo nivel técnico.
  • Si algo te molesta, dilo. Pero ten respeto por las personas y su trabajo. Además, te encontrarás con que quizás a ese programador le obligaron a hacerlo así, o quizás era su primer trabajo (todos hemos tenido un primer trabajo, y un segundo trabajo).
  • Controla tu ego. No puedes imponer a todo el mundo trabajar como te gusta. Porque se trata de eso: tu gusto.
  • No confundir lo anterior con normas de codificación. Si el proyecto o la empresa (o el cliente), tiene unas normas de codificación, hay que seguirlas. Peor que ver código mal hecho, es ver código hecho de dos formas distintas en función de miembros del equipo disciplinados, y los “libres y ajenos a toda norma”.
  • las normas de codificación, y sobre todo, las relativas a los comentarios, han de ser muy simples. Un comentario no es tan importante como para perder tiempo con 200 páginas de normas y un curso intensivo de 3 días.
  • El comentario no nos va a dar de comer: el código sí. Dicho esto, no significa que debamos ignorar y eliminar los comentarios. Si cada palabra clave o sintaxis del lenguaje que no nos gusta o “nos parece” poco útil se eliminara, os aseguro que entre unos y otros, sólo dejaríamos en el código líneas en blanco.
  • Todos dejamos código basura. (unos más que otros,es cierto). Pues también hay comentarios basura. Y contra ambos hay que luchar.
  • En tu empresa, en tu proyecto, adopta una forma de comentar simple y efectiva, minimalista. Usa sólo lo imprescindible y haz que todos lo adopten. Si trabajas solo, ten en cuenta que tu código o lo pueden usar en otros proyectos, o ya se está integrando en otros proyectos. Recuerda: hazte respetar respetando tú antes la forma de trabajo de los demás.

¿Estáis de acuerdo? ¿O sois defensores de los comentarios? ¿O abogáis por su más absoluta erradicación?
Por cierto, habrá que acuñar el término “Genocida de Comentarios”, si esto llegara a ocurrir 😉
Y bueno, creo que ya vale para una entrada un tanto improvisada.
Un saludo a todos.

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.

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.