Aunque pueda parecer mentira, lo más difícil en un proyecto de desarrollo de software es descubrir qué es lo que realmente quiere el usuario y qué es lo que espera del mismo.
En el mundo académico generalmente siempre se parte de que se conocen los requisitos, cuando en realidad es lo más difícil de obtener. Se especifican técnicas que ayuden a determinar cuáles son, pero generalmente los esfuerzos se dirigen más a lo que es la propia ingeniería del software y a la programación que si bien son importantes (tremendamente importantes, ya que desde otra perspectiva, de nada vale tener una buena materia prima de entrada, si después la ejecución no es buena y/o se obtiene un producto inmantenible), requieren que su entrada sea buena, ya que un desarrollo de software será tan bueno como claro se tenga lo que quiere el usuario, es decir, se podrá tener una ejecución impecable pero si el producto no hace lo que el usuario quiere o si hace lo que quiere el usuario pero no de la forma que quiere, todo el esfuerzo de ingeniería del software y desarrollo servirá exclusivamente para que retocar el software no sea tan costoso (que no es poco, pero que a estas alturas siempre será más caro que si desde el principio se hubiera determinado qué es lo que se quiere).
Los desarrolladores tienden a dar menos importancia a la fase de análisis y dar cada vez mayor trascendencia a la construcción. Estas prisas ni van a hacer que el producto sea mejor, ni van a provocar que el producto lo tengamos antes (es posible que lo entregues incluso antes de plazo, pero después prepárate a llevarte haciendo correctivos, mucho tiempo). El análisis es fundamental hacerlo de la mejor manera posible y eso requiere ciertas habilidades, ya que captar lo que el usuario requiere no es nada fácil, cierto es que el proyecto tiene que seguir hacia adelante y no podemos estar eternamente en el análisis, por ese motivo la clave es dedicarle la atención que se merece, no considerar que es un mal necesario (o innecesario) por el que hay que pasar y que a partir de él se genera el resto del proyecto: diseño, construcción e implantación del sistema de información.
El análisis no es una barra libre, es decir, el usuario pedirá cosas que no son posibles. Es importante que cuando un usuario pida funcionalidades que no se les van a poder ofrecer o que su complejidad es considerable, se les exponga con claridad y se trate o bien de descartarla (y ver si realmente ese descarte impactará en su impresión final del sistema) o de buscar una solución más simple. Por regla general, si a los usuarios se les explican las cosas terminan siendo bastante sensatos y si no lo son y muestran malestar o son insensatos tampoco pasa nada, ya que si algo no se puede hacer, no se va a poder hacer y mejor que se enfade ahora, que llevarse la impresión o expectativa que va a tener una funcionalidad que sabemos a ciencia cierta que no va a ser posible.
El análisis no consiste solo en los requisitos, es mucho más: obtener el modelo de datos, obtener la interfaz de usuario, definir casos de uso (al menos los más importantes), etc… y es muy importante cerrarlo con el usuario.
Cerrar el análisis no es cerrar la puerta completamente, ya que cuando el usuario empiece a ver el producto en diversas fases de su desarrollo descubrirá cosas nuevas y eso es normal porque por mucha capacidad de abstracción que se tenga y por muy buen trabajo que hayan realizado los analistas, es imposible hacer el trabajo perfecto. Ser flexible no implica tener barra libre, ya que estar continuamente retocando diseños y desarrollos es tremendamente costoso. Si el usuario quiere empezar a cambiar muchas cosas, habría que plantearse parar y volver a repasar con el usuario lo que quiere, eso tiene su coste y el usuario deberá saberlo desde el principio del proyecto, es como si cuando tienes tu casa a medio construir quieres empezar a hacer cambios, eso es siempre más costoso que si se hace sobre plano, ya que ahí lo único que se necesita es una goma de borrar.
La conciencia de que es muy difícil acertar con lo que se quiere el usuario es lo que ha provocado la aparición de muchas metodologías ágiles, basadas en obtener resultados mediante aproximaciones sucesivas o iteraciones. Me parecen soluciones bastante aceptables, incluso óptimas en entornos donde resulta complicado obtener del usuario lo que quiere. No hay que tener medio a variar de una metodología más clásica a otra más ágil si se aprecia que es la mejor solución para un proyecto concreto.
También me resulta aceptable aplicar diferentes estrategias para acertar lo máximo posible en el análisis: realizar prototipos, simulaciones, etc… y no tener nunca miedo en preguntar al usuario ninguna duda, aunque ya te lo haya explicado diez veces.
Jummp 