Arquitectura y Preventa

En esta ocasión hablaré acerca del uso de técnicas de desarrollo de arquitectura de software como parte de la etapa de preventa de los proyectos de software.

Por preventa me refiero a la etapa que ocurre cuando se hace una propuesta de solución para desarrollar un sistema de software. El cliente típicamente solicita propuestas a varios proveedores, da cierto periodo de tiempo para recibir propuestas (que puede ir de unos cuantos días a algunas semanas), y selecciona una propuesta/proveedor para realizar el proyecto.

Tradicionalmente se piensa que el desarrollo de la arquitectura inicia hasta la operación de un proyecto, sin embargo y como describiré en esta columna, es conveniente iniciar las actividades de desarrollo de arquitectura desde la etapa de preventa con el fin de lograr una propuesta más pertinente tanto para el cliente como para la organización que planea llevar a cabo el proyecto.

Preventa

La preventa se enfoca en establecer por un lado el alcance del proyecto y, por el otro, una estimación del tiempo y costo que llevará la realización del proyecto de desarrollo. La estimación que se genera durante la preventa permite al cliente tomar la decisión de si acepta o no que se realice el proyecto. Aunque en este artículo me estaré refiriendo a la preventa en un contexto de desarrollo de software a la medida, lo que aquí describo puede aplicarse también en otros contextos.

La preventa cubre actividades de la fase de inicio y planeación del ciclo de vida tradicional de la administración de proyecto. Sin embargo, dado que el propósito de la preventa es conseguir la aprobación de la realización del proyecto, muchas veces las actividades que se realizan durante la preventa son menos detalladas que lo que se hace una vez que el proyecto ha iniciado de manera formal. Por ejemplo, durante la preventa es muy probable que no se tenga claridad sobre quiénes serán las personas específicas que ejecutarán el proyecto; simplemente se determina cuántas personas y con qué perfiles se necesitarían para llevar a cabo el proyecto de acuerdo a la solución y tiempos propuestos.

Hay que señalar que durante la preventa se tiene un contexto particular y complicado, en el cual muchas veces se deben considerar:

• Información limitada: Generalmente no será sino hasta que se ejecute el proyecto que se levantarán los requerimientos de forma detallada, por lo que al momento de la preventa sólo se cuenta con requerimientos de alto nivel (que aquí llamaremos “características”). La figura 1 muestra un diagrama basado en la pirámide de requerimientos de Leffingwell donde está marcado en rojo el contexto de requerimientos con el que operamos durante la preventa.
• Poco tiempo: Muchas veces las propuestas de preventa deben ser desarrolladas en tiempos cortos. Esto es porque generalmente el cliente solicita que se le entregue una cotización rápidamente pero, también, porque la empresa de desarrollo no desea dedicar demasiado esfuerzo en una actividad que muchas veces no se cobra y para la cual no hay garantía que haya un beneficio a largo plazo.

Desarrollo de arquitectura durante la preventa

Uno de los aspectos fundamentales del trabajo que se realiza en la preventa es la estimación. Lograr una estimación adecuada muchas veces requiere de establecer un esbozo de solución, por ejemplo, para dimensionar el hardware que se debe adquirir como parte del proyecto o para conocer el tipo de recursos que deben ser asignados o contratados para la ejecución del mismo.

Es en el desarrollo de esta solución preliminar que las técnicas de desarrollo de arquitectura de software pueden aportar beneficios importantes si dichas técnicas son adaptadas para el contexto particular de la preventa. Recordemos que el ciclo de vida de la arquitectura de software consta de 4 etapas que incluyen requerimientos, diseño, documentación y evaluación (ver SG #27). A continuación veremos de qué manera puede ser adaptada cada una de estas etapas para el contexto de la preventa.

Drivers de arquitectura durante la preventa

Recordemos que dentro de los requerimientos de un sistema de software, una parte de ellos es la que influye de manera decisiva sobre la arquitectura. Estos requerimientos son conocidos como drivers de la arquitectura e incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG #28).

Como mencioné previamente, al momento de realizar la preventa de un proyecto no se cuenta con requerimientos detallados del proyecto, ya que en general estos no serán levantados y especificados sino hasta que el proyecto esté siendo ejecutado. Muchas veces sólo se dispone de características o requerimientos de alto nivel. Con el fin de poder diseñar una solución preliminar con el fin de estimar, es importante que durante la preventa se considere obtener drivers de preventa que incluyen:

• Características funcionales. A diferencia de los drivers tradicionales en donde sólo se considera la funcionalidad primaria, en general en la preventa es necesario considerar toda la funcionalidad pues la estimación del proyecto debe considerar todas las características funcionales del mismo.
• Características de atributos de calidad. Durante la preventa es complicado hacer un levantamiento detallado de los atributos de calidad, y más particularmente, especificarlos como escenarios. Dos aspectos que se deben cuidar particularmente son, sin embargo, el identificar las categorías de atributos de calidad más relevantes para el proyecto y, por otro lado, un rango preliminar en relación con las métricas asociadas a estos atributos de calidad.
• Restricciones. Es necesario identificar desde el inicio las restricciones al diseño de la solución. En particular es importante identificar restricciones que pueden influir en la estimación y que pueden tener que ver con el tipo de tecnología a utilizar, los sistemas con los que interactúa el sistema que se va a desarrollar y el entorno de operación del sistema.

Diseño de arquitectura durante la preventa

Una vez que se tienen identificados los drivers de preventa, es posible proceder al diseño de la solución. Algo que es importante considerar es que durante la fase de preventa, el objetivo principal del diseño de la arquitectura es de establecer una estructura que permita estimar el proyecto. Lo anterior diferencía el diseño de arquitectura que se hace en preventa del diseño de arquitectura que se hace durante la operación de un proyecto (ver SG #29). Generalmente el tiempo con el que se cuenta para diseñar la arquitectura durante la preventa es corto por lo que el nivel de detalle de la solución muchas veces es limitado. Con el fin de lograr la identificación de elementos que permitan realizar la estimación, es recomendable establecer estructuras generales de un punto de vista lógico y de un punto de vista físico. Cabe señalar que esto puede verse como la realización de rondas iniciales de diseño utilizando el método de diseño guiado por atributos o ADD.

Estructuración general del sistema de un punto de vista lógico

La estructuración general del sistema de un punto de vista lógico consiste en identificar, por un lado, el estilo arquitectónico que se usará y, por otro lado, los componentes que deberían soportar el conjunto de características funcionales del sistema. Para lograr esta descomposición, que tiene un enfoque funcional, es recomendable hacer uso de arquitecturas de referencia que definen la estructuración general de sistemas para dominios aplicativos bien establecidos. Un ejemplo de ello es una arquitectura de referencia para aplicaciones web empresariales, ya que establece las capas así como los tipos de componentes de este tipo de arquitectura.

Figura 1. Contexto de preventa.

Otro aspecto que puede ser importante en este punto es la identificación de las tecnologías asociadas con las partes que define la arquitectura de referencia. La identificación de tecnologías puede obedecer a las restricciones y también a los atributos de calidad del sistema.

Estructuración general del sistema de un punto de vista físico

La estructuración general del sistema de un punto de vista físico consiste en mapear los elementos de la estructura lógica hacia elementos físicos, más particularmente, nodos en los cuales se ejecutarán las partes de la aplicación. De esta forma se establece la manera en que será implantada la solución. La identificación del esquema de implantación es fundamental para establecer una estimación de los recursos físicos necesarios para el desarrollo de la solución.

El esquema de implantación de la solución que se elige obedece, en general, a los atributos de calidad del sistema pero también a las restricciones. En general son atributos de calidad relacionados con la disponibilidad y el desempeño los que influirán directamente sobre el esquema de implantación de la solución. Por ejemplo, cuando se tienen requerimientos relacionados con una alta disponibilidad, muchas veces se opta por un esquema de implantación que implica la redundancia.

Documentación de arquitectura durante la preventa

La documentación del diseño de una arquitectura consiste en la representación de las distintas estructuras a través de vistas (ver SG #30). En el contexto de la preventa, en general la documentación que se produce del diseño es información que será usada como parte de la propuesta técnica que se le entrega al cliente, por lo que no es tan conveniente realizar una documentación demasiado técnica (a diferencia de lo que se hace durante la ejecución del proyecto). Muchas veces la documentación se limita a un diagrama usando un lenguaje menos formal, o lo que se conoce como diagrama de “Marketecture”.

Evaluación de arquitectura durante la preventa

Una de las actividades fundamentales del ciclo de desarrollo de la arquitectura es la evaluación del diseño (ver SG #31). Recordemos que el propósito de la evaluación es la identificación de riesgos relacionados con la toma de decisiones relativas al diseño.

Al igual que lo que se realiza como parte del ciclo de desarrollo de la arquitectura, es posible realizar una evaluación del diseño durante la preventa. En una evaluación basada en escenarios tradicional, se toman escenarios y se revisa detalladamente la manera en que el diseño de la arquitectura los soporta. Durante la preventa, el nivel de detalle del diseño del que se dispone no es el mismo. De hecho, muchas veces no se han tomado decisiones finas enfocadas a soportar escenarios concretos dado que no se dispone de ellos. Por lo anterior, la evaluación de la arquitectura durante la preventa no puede ser realizada de la misma manera que lo que se realiza durante la operación del proyecto.

En general, durante la evaluación de arquitectura en preventa, lo que se evalúa son las decisiones primarias tomadas en relación al diseño: la elección del tipo de arquitectura de referencia, las tecnologías o el esquema de implantación. Generalmente la evaluación de arquitectura identifica riesgos asociados no únicamente con el diseño sino también con otros aspectos tales como los requerimientos. Por ejemplo, si al momento de realizar la evaluación se observa que no hay métricas asociadas a los atributos de calidad (como sucede frecuentemente), esto representa un riesgo.

Finalmente, puede ser conveniente que como parte de la evaluación, se revise el plan que se tiene del proyecto para evaluar si la estrategia que se está considerando es adecuada en relación a los riesgos que se han identificado.

Conclusión

La preventa de un proyecto juega un papel crítico en relación a la aceptación de un proyecto de desarrollo. El utilizar métodos adaptados de desarrollo de arquitecturas de software durante esta etapa no sólo es posible sino que es recomendable pues puede permitir que se establezca una solución más adecuada y se realice una mejor estimación.

En la URL siguiente el lector podrá encontrar un video de la presentación que realicé este año en la conferencia SATURN 2014 y de la cual se deriva este artículo: http://goo.gl/5ZC8W4