Tres formas diferentes de ver el producto Análisis Funcional

En las decisiones que tenemos que tomar respecto de nuestros proyectos deberíamos plantearnos lo siguiente:

TRES VARIANTES A LA HORA DE VER Y EMPLEAR EL ANÁLISIS

• El proyecto utiliza el modelo de análisis para describir los resultados del análisis, y mantiene la consistencia del modelo a lo largo de todo el ciclo de vida del software.

• El proyecto utiliza el modelo de análisis para describir los resultados del análisis pero considera a este modelo como una herramienta transitoria e intermedia. Más adelante, cuando el diseño y la implementación están en marcha, se deja de actualizar el análisis. Cualquier “tema de análisis” que aún quede se resuelve como parte integrada dentro del trabajo de diseño.

• El proyecto no utiliza en absoluto el modelo de análisis para describir los resultados del análisis. En cambio, el proyecto analiza los requisitos como parte integrada en la captura de requisitos o en el diseño. Puede ser justificable si, por ejemplo, los requisitos son muy simples y/o son bien conocidos, si es fácil identificar la forma del sistema, o si los desarrolladores cuentan con una cierta comprensión, intuitiva pero correcta, de los requisitos, y son capaces de construir el sistema de manera correcta.

Para las dos primeras se debe sopesar las ventajas de mantener el modelo de análisis con el coste de mantenerlo durante varias iteraciones y generaciones. Se debe hacer un análisis coste/beneficio.

La tercera variante se debería solo emplear para sistemas extraordinariamente simples.

La decisión de una u otra variante debe ir en función de aspectos como Grado de confianza con el cliente, Madurez de nuestros equipos, Conocimiento del negocio, etc…, pero cualquiera que sea nuestra elección, deberíamos respetarla a lo largo del ciclo de vida del proyecto.