Este documento especifica de una manera clara y general cuales son los procesos que se realizan en la empresa u organización del cliente según la primera reunión que se tuvo en la empresa, para poder llegar entre las partes a un acuerdo sobre el entendimiento del problema real que tiene el cliente y no llegar a desarrollar una solución ideal a un problema que no existe. Esta solución se hará siguiendo el patrón mas adecuado entre costos-tiempo-beneficios.

Para desarrollar una solución a un problema real hay que tener claro los principios en los que se esta fundamentando el problema actual, es decir, entre las partes no debe quedar agujeros negros de dudas con respecto al problema a solucionar, puesto que a la hora de empezar a desarrollar el software estas dudas pueden crecer o confundir de tal manera que se dificulte el proceso de desarrollo de la solución, lo que conllevaría mas tiempo y costos. Por ello este primer documento aumentará la seguridad de que las partes entienden la situación a la que se enfrentan para encontrar una solución segura, estable y adecuada para el cliente, así poder evitar el desarrollo de un proyecto software no aplicable.

No solamente se debe centrar la reunión en hablar de la situación a la que hay que darle solución, por el contrario, es necesario e importante iniciar la reunión conociéndose entre las partes. Una buena y corta presentación de los ingenieros de software hacia el cliente y su equipo de colaboradores transmite una sensación de claridad mental a lo que van a decir y hacer en la reunión, con esto se logra que el cliente asegure la forma en la que se puede expresar en la reunión, al igual que hace que el cliente se sienta con mas confianza.

Para el equipo de ingenieros es aun más importante conocer la empresa u organización a la que pertenece el cliente, a que sección o departamento esta dirigido el proyecto a tratar, que beneficios obtendrán, a que se dedica la empresa del cliente, para determinar el ámbito del proyecto y el Modelo de Procesos de Negocios (del cual hablaremos en otra oportunidad, sobre como usar modelos para representar la realidad y generar soluciones bajo UML).

Se debe tener claro en este punto que el FEA se escribe posteriormente a la ejecución de la primera reunión con el cliente en un máximo de 10 días y no pretende ser una propuesta con costos y tiempo establecidos, solo tiene como objetivo aterrizar las ideas que se generaron en la reunión, al igual que en aclarar a que se dedica la organización o empresa del cliente para saber con que recursos se cuentan, al mismo tiempo describe lo que se ha entendido por parte del equipo de ingenieros de software sobre cada uno de los procesos que conforman la situación a solucionar, para llegar a un acuerdo de entendimiento entre las partes.

Es importante describir la Función General del Software, que básicamente define lo que el software hará o solucionará cuando se halla desarrollado, instalado y se este usando, para ello los ingenieros deben tener una excelente visión de lo que desea el cliente, esto permitirá delimitar la funcionalidad del software, sin embargo, es muy probable que el documento no sea del todo correcto, lo cual es el objetivo del mismo, puesto que con el, él cliente podrá mejorar la retroalimentación con el equipo de ingenieros de software en la próxima reunión, garantizando así que ambas partes lleguen a un punto de acuerdo del sistema a desarrollar.

En resumen este documento escrito por el equipo de ingenieros de software expone al cliente los siguientes puntos:

• Objetivo del documento.

• Función de la empresa u organización del cliente.

• Procesos que conforman el sistema actual.

• Análisis de entendimiento de los procesos.

• Función general del software.

• Conclusiones (del equipo de ingenieros).

• Anexos (documentos con los que el equipo de ingenieros se basaron para escribir este documento, entregados por el cliente o desarrollados por el equipo de ingenieros)

Pueden haber mas pasos para este documento, todo depende de como se lleve la reunión, también de la experiencia de los ingenieros, las circunstancias, entre otras cosas; algunas veces este documento no es necesario, por ejemplo, cuando se tiene un pliego de peticiones o requerimientos ya establecidos por el cliente, en donde explican claramente que es lo que necesitan, esto se acostumbra hacer cuando hay licitaciones del gobierno o empresas privadas grandes que cumplen con estándares interacciónales de calidad o simplemente son muy organizados y tienen claro que es lo que desean de un software, lo cual los ha hecho generar un análisis previo de la situación a la que desean darle una solución.

Escribe tu comentario aquí.