Arquitectura Funcional

Suelo echar de menos en la mayoría de las organizaciones, un área de Arquitectura Funcional. El nombre plantea confusión, para mí la Arquitectura Funcional debe plantear soluciones funcionales a problemas como:

• Aplicaciones orientadas a obtener un Producto con "n" clientes.
• Aplicaciones Multicanal.
• Aplicaciones BPM.
• Aplicaciones de Portal.
• Aplicaciones ERP-CRM.
• Definición de Agrupaciones o paquetes funcionales.
• Definición de Fases.

Lo que deben describir entre varios aspectos, son los posibles patrones de análisis a utilizar, ¿cómo enfocar funcionalmente cada tipo de aplicación?, desde la toma de requisitos hasta el diseño funcional.

Esta materia definirá estrategías comunes ante los mismos problemas. No es metodología, ya que no dice por ejemplo cómo hacer un modelo de casos de uso; lo que si hará será aconsejar en el cómo plantear un modelo de casos de uso ante una tipología de aplicaciones.

A partir de una estrategía funcional clara, podremos elegir el mejor ciclo de vida posible para orquestar el proceso de desarrollo.

Consideraremos cada uno de los tipos de aplicaciones planteadas, como una Arquitectura Funcional de Referencia. Por ejemplo, cuando nos venga un proyecto que tiene que desarrollar una aplicación SAP, utilizaremos la arquitectura de referencia ERP-CRM para obtener un Diseño Funcional que cubra las necesidades de este tipo de aplicaciones. Y eso sí, para el siguiente no tendremos que inventar nada.

Dos maneras de enfocar un nuevo Proyecto Software

A la hora de comenzar un proyecto debemos analizar a nuestros participantes, esto nos tiene que permitir enfocar el modo de relación en el proyecto, el cuál es fundamental para conseguir los objetivos que pretendemos.

Tendremos:

• Proyecto con participantes que van a trabajar en plan "Buen Rollo". Esto no deja de ser síntoma que algo tienen que esconder, pero aunque esto sea así, el clima que se forma excusa los fallos y apoya continuamente. Si no se controla se convierte en un cachondeo ya que los que fallan se piensan que todo el monte es orégano.
• Proyecto con participantes que van a trabajar en plan Borde. Todos muy profesionales y a la mínima que se falla en algo, hachazo. Muy efectivo de inicio pero poco solidario y a veces finalmente no muy productivo, ya que los que fallan se alían y hacen la vida imposible al resto.

Yo prefiero trabajar con los del Buen Rollo, aunque cuando me ha tocado ser él que dirige, a veces es un poco estresante. Si hay algún miembro caradura se puede fracasar y tener que ir al plan Borde.

Es importante que ya de inicio en la reunión de lanzamiento, te posiciones. A mí me ocurrió hace poco que en una reunión en la que vas de "buen rollo", una superlista empezó a atacar, pues nada se quita uno el traje de buenrollista y saca la coraza y la espada, y a atacar también. Finalmente, llegamos al "buen rollo", ya que la mayoría de las veces, los que van en plan "borde", no deja de ser también porque tienen algo que esconder y piensan que ponerse a la defensiva les evita que les saquen los colores.

Saludos y mi mejor "buen rollo"...

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.

Requisitos Funcionales vs Casos de Uso

En la mayoría de las organizaciones en las que he trabajado, se realiza una Toma de Requisitos bastante detallada y posteriormente un Análisis Funcional basado en los requisitos recogidos.

¿Qué es lo que se hace?, se capturan y describen los requisitos y después se traslada a un modelo de casos de uso, dónde se vuelve a describir la funcionalidad deseada; posiblemente si se hace bien, con un enfoque más orientado al usuario y con una estructura más clara.

Ahora bien, ¿qué conseguimos con esto?, más horas de análisis, más horas de validaciones, tener repetido lo que tiene que hacer el sistema en dos artefactos diferentes, inconsistencias, etc...

La captura de los requisitos se debe realizar a través de los casos de uso. Si se decide no utilizar casos de uso, se puede realizar a través de un documento de análisis que contenga las funcionalidades y su estructuración.

Si para realizar el análisis de una aplicación, primero se capturan las necesidades, luego se hace un documento de toma de requisitos que además se tiene que validar y finalmente se hace un modelo de casos de uso (con su validación correspondiente), daremos la razón a todos aquellos que piensan que el proceso de Análisis es demasiado pesado.

CONCLUSIÓN FINAL: Los requisitos funcionales se deben capturar a través de los casos de uso. No se debe perder el tiempo en hacer un documento de requisitos funcionales.

Más adelante hablaremos sobre las Historias de Usuario, aunque para ello tendremos que poner el contexto del tipo de proyecto que manejamos.

Aclaración de términos para Análisis

Hola, vamos a aclarar algunos términos que normalmente mezclamos equivocádamente. 

• Necesidad: Lo que pretende el cliente o desea que se le proporcione para su aplicación.
• Lo que se está pidiendo que el sistema haga.
• Se consideran equivalentes los siguientes términos:
• NECESIDAD = ISSUE = CARACTERÍSTICA = REQUERIMIENTO = REQUISITO CANDIDATO = Requisitos de Usuario. 

• Requisito: También denominado Requisito del Sistema. Capacidad que debe tener el sistema para satisfacer las necesidades de los usuarios del sistema. Incluye Requisitos Funcionales y Requisitos No Funcionales.
• Lo que se necesita para cumplir con lo que se está pidiendo que el sistema haga.

• Caso de Uso: Secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia.
  • Estructuración de la funcionalidad requerida en el sistema, a través de secuencia de pasos e interacciones con sistemas externos (usuario).

Ejemplo:

Necesidad: Contestar un mensaje de correo.

Requisito: Tener un ordenador conectado a Internet; tener un software de correo electrónico; Poder seleccionar destinatarios; Poder modificar el mensaje; y más requisitos...

Casos de Uso: Seleccionar Destinatarios; Editar Mensaje; Insertar Firma; etc...

Un saludo,