Páginas

Mostrando entradas con la etiqueta toma de requisitos. Mostrar todas las entradas
Mostrando entradas con la etiqueta toma de requisitos. Mostrar todas las entradas

lunes, 10 de noviembre de 2008

Cómo crear una aplicación web. Fase I. Toma de requisitos

El primer paso de cualquier proyecto que tenga como finalidad construir una aplicación informática es escuchar a los clientes y/o usuarios para saber qué necesitan. En una primera serie de reuniones simplemente  debemos escuchar y tomar notas de las funcionalidades que debe cumplir el nuevo sistema. No debemos juzgar si tal requisito se hará de tal manera o si ese requisito es innecesario. Debemos recordar que el trabajo de crear una aplicación web debe estar orientado a la consecución de los objetivos del cliente, no a la satisfacción de los creadores. La satisfacción de los creadores (arquitectos, jefes de proyecto y programadores) debe ser la de crear un producto sin errores, escalable, on-time y que cumpla al 100% las necesidades del cliente. 

Idealmente, la toma de requisitos debe realizarse antes del presupuesto en tiempo y dinero ya que es imposible presupuestar un proyecto del que no se sabe exactamente qué se desea. La fase de la toma de requisitos debe afrontarse como una coste comercial, ya que es posible que si no se ha firmado el contrato el proyecto finalmente no se gane. En la mayoría de los proyectos para administraciones públicas o grandes empresas donde se convoca un concurso mediante RFP se comete el error de presupuestar a partir de unos requisitos redactados por el cliente de forma poco exhaustiva por lo que es fácil que aparezcan desvíos tanto en tiempo de entrega, funcionalidades o precios desorbitados.

Una vez hemos tomado nota de los requisitos el siguiente paso, ya de manera interna es ordenar esas ideas. Una buena manera de ordenar ideas es crear, repito, de forma interna, una modelo de datos a partir de las decenas y decenas de ideas que el cliente nos ha transmitido. El cliente no tiene porqué saber (según un ejemplo de aplicación tipo Facebook) si los “amigos del usuario” puede ser lo mismo a efectos de programación que un “usuario”. Debemos ser capaces de reducir todas las ideas recogidas en la primera reunión en un modelo de datos (por ejemplo un modelo entidad-relación a alto nivel).

En la siguiente reunión tomaremos el control y a partir de la lectura de nuestro modelo de datos (traducción de cajas y líneas a prosa) debemos ir confirmado con el cliente que esas son las funcionalidades lo que su empresa necesita. En esa misma reunión debemos proponer temas que puedan aportar valor al cliente y basados en nuestra experiencia: integrar aplicaciones de terceros, formas de enfocar la arquitectura de la información, software existente, etc.

Esta fase y dependiendo de la envergadura del proyecto y/o del cliente puede convertirse en iteraciones de reuniones de toma de requisitos con diferentes responsables de áreas implicadas.

Generador de prototipos para aplicaciones web

Este fin de semana he estado probando una nueva herramienta para generar prototipos de aplicaciones. En mi caso, me he centrado en probar cómo crear esos prototipos para definir aplicaciones web.

Se trata del Visual Prototyper de la empresa española JustInMind. La verdad es que las sensaciones han sido muy buenas. De una forma muy intuitiva y en poco tiempo puedes generar toda una aplicación con sus botones, combos, listados, etc. y lo más importante, dotarlos de funcionalidad para que el cliente pueda probar lo que será su aplicación antes de tirar una sola línea de código. En muchos proyectos en los que he participado esos prototipos y wireframes se realizan con un simple PowerPoint o un Word, lo que provoca que el cliente no pueda sentir la experiencia de uso de su aplicación hasta que ésta está desarrollada.

Una de las funcionalidades que más me agradó fue la de poder montar el modelo de datos (como si de una base de datos se tratara) y que el porgrama te genere los listados y los formularios de alta, baja y modificación. Perfecto.

El Visual Prototyper es muy intuitivo, sencillo, sin decenas y decenas de opciones de menú, lo que se agradece, y a la vez consigue los objetivos que cualquier analista funcional y/o arquitecto de la información necesita antes de que los desarroladores comiencen a escribir el código.

Algunos preguntas/dudas que me gustaría comentar son:
  • La creación de la documentación podría ser más sencilla (?¿)
  • No fui capaz de crear acciones de decisión, es decir, si pasa A ejectuta una acción, si pasa B, ejecuta otra acción.
  • El manual de usuario es excesivamente liviano, aunque supongo que será una de las estrategias de la empresa ya que ofrece entre sus servicios formación en la herramienta.
De todas formas este producto es muy muy recomendable para los que nos dedicamos a definir aplicaciones (si generara código XHTML ya sería la bomba).